PHNE_26771 and poor TCP sequence numbers (ISN)

[Marcin Piwko]

Guys,

I'm suplying HPUX scan data for the new report update of: http://razor.bindview.com/publish/papers/tcpseq.html

We are suprised that results we got after paches installed doesn't show any improvement of the ISN randomness.

Please let us know if all we did is correct.

The CERT report quoted here says:

For 11.00, if you want HP's solution for randomized ISN numbers then apply TRANSPORT patch PHNE_22397. Once you apply PHNE_22397, there's nothing more to do --- default is randomized ISNs.

We have HPUX11 box. We installed standard HP Quality Patch Bundle, then I went for search of the PHNE_22397. This patch is included as part of PHNE_26771 "cumulative ARPA Transport patch".

We installed a bundle of all patches required:

[ /root ] qqlka# swlist BUNDLE
# Initializing...
# Contacting target "qqlka"...
#
# Target: qqlka:/
#

# BUNDLE B.11.00 Patch Bundle
BUNDLE.PHCO_23651 1.0 fsck_vxfs(1M) cumulative patch
BUNDLE.PHKL_25525 1.0 Probe,IDDS,PM,VM,PA-8700,asyncio,T600,FS
BUNDLE.PHKL_25475 1.0 PM cumulative patch
BUNDLE.PHKL_22840 1.0 IDS/9000; syscalls related to file/socket
BUNDLE.PHNE_26771 1.0 cumulative ARPA Transport patch
BUNDLE.PHKL_24027 1.0 VxFS 3.1 comulative patch
BUNDLE.PHKL_20016 1.0 2nd CPU not recognized in G70/H70/I70
BUNDLE.PHKL_18543 1.0 PM/VM/UFS/async/scsi/io/DMAPI/JFS/perf patch

As you see the patch is installed. Ufortunately there is no any significant improovement in comparisation to last year's results.

Please let us know if everything we did is correct.

If you want to discuss details in private
please reply to email address: tenox@tenox.tc

Thanks.

[Victor_5]

What is the output of
swlist -l fileset -a state PHNE_26771

swlist -l fileset -a state PHNE_22397?

[Victor_5]

More info...

I checked one of my 11 boxes, I did not install PHNE_26771 yet, since PHNE_26771 supersedes PHNE_22397, if your swlist is correct, it is no need to worry about PHNE_22397 any more, my suggestion is open a call with HP and ask a patch expert's help, good luck.

[Marcin Piwko]

The output is:

[ /root ] qqlka# swlist -l fileset -a state PHNE_26771
# Initializing...
# Contacting target "qqlka"...
#
# Target: qqlka:/
#

# PHNE_26771
PHNE_26771.CORE2-KRN configured
PHNE_26771.NET-KRN configured
PHNE_26771.NET-PRG configured
PHNE_26771.NET-RUN configured
PHNE_26771.NET2-KRN configured
PHNE_26771.NMS2-KRN configured
[ /root ] qqlka# swlist -l fileset -a state PHNE_22397
# Initializing...
# Contacting target "qqlka"...
ERROR: Software "PHNE_22397" was not found on host "qqlka:/".

Yes, you are completely right about PHNE_22397 since it should beincluded in PHNE_26771. My question was because I want to be 100% sure I did everything OK. According to HP PHNE_22397 solves the problem completely and PHNE_26771 is is the latest/best bundle including that fix. Thus all I did is right and this should solve the problem? Am I right?

I don't want to contact HP yet since I'm not solving any problem - I'm just testing HP's solution.

Many thanks!

[Victor_5 · Accepted solution]

Hi Marcin:

As far so I learned, based on the info you provided, I did not see anything wrong on your side, your swlist also is correct, I agree with your understanding.

[Dave Unverhau_1]

Hi Marcin,

I did some research on PHNE_26771 and I found no indication that anything has changed over the previous patches regarding the RFC 1948 implementation. However, I did discover the following information, which may explain your results:

==============================================
The RFC 1948 is now implemented for computing TCP
ISN values.
By default, the support for RFC 1948 is turned off.
It can be turned on by using
the ndd variable, tcp_isn_passphrase .
The secret passphrase can be of any length, but only
the first 32 characters will be retained.
The passphrase, once set, should not be changed,
except possibly at reboot.
For example:
ndd -set /dev/tcp tcp_isn_passphrase "rfc 1948"
will turn on the support for RFC 1948.
========================================

So, until you enable RFC 1948 support, your ISN randomization should be no different than your pre-patch results.

I hope this helps!

Regards,

Dave

[Marcin Piwko]

Dave,

Thanks for the response! I will test it stright away. I found that variable myself but according to HP "you don't have to do anything else" so I didn't bother to change that. The patch was supoused to "fix the problem" without setting anything else on.

Can you let me know where did you found that information?

Thanks very much!
Antoni

[Dave Unverhau_1]

Antoni,

I found that reference on an internal HP site that tracks software defect reports and fixes. The information I provided to you is not tagged for internal use only or confidential, so I felt that it was something that needed to be shared.

I agree, the info that you had seen describing the functionality as "enabled by default" is misleading. I'm going to try to submit a request to have the CERT report amended to provide the correct information.

I'm an HP "field guy", so I don't know what kind of results I'll get with the lab folks on getting such verbiage changed, but I'll try (in the hopes that somebody else doesn't have to find out the hard way).

Please post a followup response so I (and any other readers of this thread) know for sure that setting the variable did provide the extra ISN randomization.

Best Regards,

Dave

[Dave Unverhau_1]

Antoni,

I was looking through the README for PHNE_26771 and I missed this at first, as it buried pretty deeply, but I guess the following text spells it out for us:

PHNE_26445:
( SR number: 8606213513 ; Defect: JAGad82705 )
Symptom:
Systems relying on random increments for
choosing less predictable TCP ISN values,
are still vulnerable to statistical attacks.

Defect Description:
The RFC 1948 ("Defending against sequence
number attacks") is not supported.

Resolution:
The RFC 1948 is now implemented for computing TCP
ISN values.
By default, the support for RFC 1948 is turned off.
It can be turned on by using
the ndd variable, tcp_isn_passphrase .
The secret passphrase can be of any length, but only
the first 32 characters will be retained.
The passphrase, once set, should not be changed,
except possibly at reboot.
For example:
ndd -set /dev/tcp tcp_isn_passphrase "rfc 1948"
will turn on the support for RFC 1948.
---------------------------------------------

I did place a request with WTEC for clearer explanation of what is required to enable RFC 1948 compliance in the "special installation instructions" portion of the patch README. I also suggested that contacting CERT to update the advisory might be a good idea.

Best Regards,

Dave

[Marcin Piwko]

Guys,

Thanks for all follow ups and informations.
Yes, the patch plus "tcp_isn_passphrase" set enchace the randomness and enables RFC 1948.

The other problem is, as I said before, the
results are rather poor and the enchanced
randomnes is easy predictable. It seems to us,
the algorithm used is similar to one implemented
in Solaris.

Please wait for the final report to be completed.

For now all the patching/setting inssues thanks
to you were resolved and we are sure we used a
right combination when testing.

Again thanks for all your help, and I hope all
this will contribute to HPUX security.

M

[Ray Carlson]

I ran in to this problem and opened a software call with HP back on July 31, 2002. Some of the information obtained from HP so far is:
1) ndd -set /dev/tcp tcp_isn_passphrase "secret phrase" is lost upon reboot.
2) ndd -set /dev/tcp tcp_isn_passphrase "secret phrase" can not be set in nddconf.
3) ndd -set /dev/tcp tcp_isn_passphrase "secret phrase" has to be set immediately upon boot up.
4) There is currently no way of telling if it has been set.
An HP message dated Sep 4, indicated that a fix may be coming soon.

I hope you have better luck in getting results than I have.