TCP/IP security patch

[H_Bachner]

Yesterday, HP published Security Bulletin c01961959 (see <>).

This bulletin points to updated images for HP TCP/IP Services V5.5 ECO3 and V5.6 ECO4.

I did not look at the V5.5 stuff (yet), but got the fix for V5.6 ECO4 on Alpha.

Current ECO for V5.6 is ECO5.

The security patch contains a number of NTP related images. I compared the first image from this fix for ECO4 and the respective image in the official ECO5 kit and found the following:

image name: "TCPIP$NTP"
image file identification: "V5.6-ECO4B"
link date/time: 7-DEC-2009 16:30:34.44

image name: "TCPIP$NTP"
image file identification: "V5.6-ECO5"
link date/time: 30-NOV-2009 18:07:22.57

So the image from the the security patch is newer than that from ECO5. The ECO 5 release notes don't mention security issues for NTP (except maybe a corrected stack overflow problem for TCPIP$NTPQ, but not the other programs contained in the security patch).

Can anyone tell me:

- does ECO5 contain these fixes?
- if not, will there be a patch kit for ECO5 as well?

An interesting question remains: why does HP publish a Security Bulletin on 23-Mar pointing to a fix that os more than three months old?

Thanks for any info,
Hans.

[The Brit]

I am also running TCPIP 5.6 ECO5 on my testing system, and I am curious as to whether this security bulletin applies to ECO5.

On different note, I downloaded the ECO4 patch (backup saveset) to the same system, but I couldnt read it. I got

backup/list qxcr1000910870_v56_eco4_i64.bck;1/save_set
Listing of save set(s)

%BACKUP-E-POSERROR, error positioning DSA101:[OPENVMS.PRODUCTS.TCPIP56_E5]qxcr1000910870_v56_eco4_i64.bck;1
-RMS-F-IOP, operation invalid for file organization or device
%BACKUP-E-READERRS, excessive error rate reading DSA101:[OPENVMS.PRODUCTS.TCPIP56_E5]qxcr1000910870_v56_eco4_i64.bck;1
-BACKUP-E-BLOCKCRC, software block CRC error
%BACKUP-I-OPERSPEC
%BACKUP-I-OPERASSIST, operator assistance has been requested
%BACKUP-I-NOOPER, no operator is available to handle the request
%BACKUP-I-OPERSPEC, specify option (QUIT or CONTINUE)
Requesting PID:2020078C, Target Device:_DSA101

I downloaded in binary mode, (see attachment)

(I just know someone is going to point out some novice mistake I made.)

Dave

[H_Bachner]

Hi Dave,

binary download creates files with fixed length (ok for BACKUP), but 512 bytes record length (usually not what BACKUP expects).

On a sufficiently new system, just add the /REPAIR qualifier to your BACKUP command.
On older systems, use
$ SET FILE /ATTRIB=LRL=32256 saveset.bck

The actual record length may vary and can be found out once BACKUP /LIST gets sufficently far to display the savest block size, or you DUMP the first block of the saveset and get the required record size (in hex) at offset 28(hex).

Hans.

[H.Becker]

>>>
(I just know someone is going to point out some novice mistake I made.)
<<<
You may want to get Hein's magic spell - FIXSAVESET.COM which will print a
RFM was FIX, MRS = 512, LRL = 512.
and do a
$SET FILE /ATTR=(RFM=FIX, MRS=32256, LRL=32256)

[Art Wiens]

Using FTP to download VMS savesets doesn't usually "work well". Try the recommended:

SET FILE/ATTRIBUTES=(RFM:FIX,MRS:32256,LRL:32256,RAT:NONE) file.bck

to fix your saveset.

Cheers,
Art

[Art Wiens]

Doh! That's what happens when you take the time to go get a coffee refill!

Cheers anyways,
Art

[Volker Halle]

Hans,

TCPIP V5.6 ECO 5 seems to already contain this fix:

ECO 5 updates
-------------
16-JUN-2009 Alpha and INTEGRITY SERVERS

Problem:

A stack buffer overflow problem exists in the NTPQ program.

Deliverables:

TCPIP$NTPQ.EXE

Reference:
SSRT#090073, TCPIP_BUGS Note 3709


Volker.

[Volker Halle]

Hans,

TCPIP V5.5 ECO 3 is still the 'current' patch (released on 21-FEB-2008).

I can't answer your question about the 'age' of the fix, but the comment in the V5.6 ECO 3 release notes seems to indicate, that this part of the problem already got fixed on 16-JUN-2009.

Volker.

[Ian Miller.]

and to fix the backup saveset try the magic

BACKUP/REPAIR command :-)

(worked for me on on VMS Alpha V8.3 YMMV)

[Hoff]

There's an Apache Secure Web Server (SWS) patch that just dropped, too.

http://www13.itrc.hp.com/service/cki/docDisplay.do?docId=emr_na-c02002308

[H_Bachner]

@Volker:

>TCPIP V5.6 ECO 5 seems to already contain this fix:

I found the description of the TCPIP$NTPQ fix (see base note), but the patch kit consists of all seven TCPIP$NTP*.EXE images which are part of the product! This allows two interpretations:

- the problem was part of some code commonly used by all NTP images
- the fix delivered all seven images routinely, e.g. to hide the security hole.

Maybe a member of the TCP/IP team is reading here...

Hans.

[H_Bachner]

@Ian:

> and to fix the backup saveset try the magic
> BACKUP/REPAIR command :-)
> (worked for me on on VMS Alpha V8.3 YMMV)

yes, this was my first suggestion too! I only wasn't sure when this qualifier was added. In the meantime I found that Guy Peleg mentioned it as part of his V8.3 Utilities Update presentation at the OpenVMS Technical Update Days in 2006.

The qualifier is still undocumented in the OpenVMS 8.4 field test release.

Hans.

[John Gillings]

BACKUP/REPAIR

>I only wasn't sure when this qualifier was
>added. In the meantime I found that Guy
>Peleg mentioned it as part of his V8.3
>Utilities Update

You should find it in anything above V8.0. Guy added it after finding one of my > decade old SPRs requesting it.

Engineering seems to have gotten a bit slack about updating documentation of late :-(

(my original request was that backup *automatically* fix broken savesets, but that seemed a bit too much!)

[H.Becker]

Backup/repair: I admit, I didn't know it, I should have attended the TUD. But I had a look at the real documentation. The code for /repair was checked into 8.3. I have no idea if it was back-ported or if there was any special image (plus CLD file) for older VMS versions. The qualifier will be documented (at least it showed in a recent checkin for the online help) in 8.4.

It seems, if you set up a symbol like backup:=backup/repair it should repair any broken saveset, automagically. But you will get an informational for both, broken and intact savesets. I didn't see that it accepts the keyword "quiet". For the other backup operations I usually use, a quick test didn't show any conflict or message when used that way.

[Malcolm Wade]

The worrying thing about this patch is that it's distributed as a simple backup save-set which you and I have to pull apart and put the images into place which as we all know is fraught with danger as I bet some customers end up with these new images in SYS$SPECIFIC:[SYSEXE] There was not even a readme or command file in the saveset which you could refer to or run to patch your system.

As someone else pointed out; the images are over 3 months old. How hard is it to produce a PCSI kit?

[Volker Halle]

Hans,

the closer you look, the more questions arise:

The V5.6 patch simply collected all *.EXE files from the NTP build directory into a backup saveset. Whether this is necessary or required, I can't tell. TCPIP ECO kits have always been full kits since around JUN-2007, so this may explain why all NTP* images are included.

One of the problems referenced in the Security Bulletin c01961959 version 1 seems to be a BIND problem (CVE-2009-0696), not a NTP problem. There are no bind images in the V5.6 patch kits.

SSRT 090245 is not referenced in the TCPIP V5.6 ECO 5 release notes, so you could assume, that this problem is not fixed in ECO 5 (or the fix is not mentioned).

Volker.

[H.Becker]

>>>
As someone else pointed out; the images are over 3 months old. How hard is it to produce a PCSI kit?
<<<

Maybe it could have been done faster and I admit I didn't look at the actual kit dates. But you are comparing link dates with the availability of all the kits. You may want to add some time for kitting and testing. Everybody wants to have the kits tested, not only the images! And if there are kits for different OS and TCPIP versions it may take a signifikant amount of time. And in this case you also want to release all kits at once or none.

>>>
the closer you look, the more questions arise:
<<<

That's a problem and needs to be reported/addressed. ECOs should be well documented and there shouldn't be any uncertainty what needs to be installed in case of security related kits.

Just my EUR .02

[Volker Halle]

Hartmut,

thanks for your 'encouragement'. I've informed the Office of OpenVMS Programs about these issues.

Volker.

[Ian Miller.]

There is some 'discussion' going on already in HP about this and I've pointed people at this thread.

If Volker did not already have one, I'd nominate him for a VMS Ambassadors Spirit Award :-D

[Volker Halle]

Hans,

more findings and questions:

the V56_ECO4 patches (both Alpha and I64) contain a TCPIP$NTPTRACE image from 30-MAR-2004.

the V55_ECO3 patches do NOT contain this image.

So either NTPTRACE is not affected, then why ship it ? Or it has been 'forgotten' to be fixed and shipped.

Volker.

[Volker Halle]

Hans,

HP really seems to be listening !

Now there is rev. 2 of the security bulletin c01961959

There are now also patches for TCPIP V5.6 ECO 5.

And the wrong reference to CVE-2009-696 (BIND) has been removed.

Volker.

[Ian Miller.]

A round of applause for Volker :-)

Someone buy him a beer

[Volker Halle]

Ian,

hold back on the applause please...

The patches for TCPIP V5.6 ECO 4 and ECO 5 for Alpha and I64 ship TCPIP$NTPTRACE linked 30-MAR-2004 ! Looks like this image has NEVER been relinked since TCPIP V5.6 SSB ?!

The patches for TCPIP V5.5 ECO 3 do NOT ship TCPIP$NTPTRACE images.

So there still remains the question:

Is TCPIP$NTPTRACE affected by this security problem ? If so, why has it not been relinked. And if NOT, why is it being shipped at all ?

To me, it looks like all the .EXE files from the build directory of NTP have been shipped in this kit and not just the affected images.

And to build and ship the V5.6 ECO 5 images took less than 16 hours, so the previous speculation about 'intensive testing of the patched images delaying the issue of the security fixes', does not seem to have affected this set of fixes.

Volker.

[Volker Halle]

For both OpenVMS I64 and Alpha, TCPIP$NTPTRACE.EXE has NEVER been re-linked since V5.5 (30-MAR-2004).

This seems to be very unusual, all other NTP images have been relinked for each new SSB version and for each patch.

Maybe the NTP build is broken since V5.5 and missing the re-build of TCPIP$NTPTRACE...

FWIW,

Volker.

[John28]

Does this vulnerability exist for TCPIP V5.4?

Thanks for any info...

John