Bugtraq mailing list archives
_very_ poor ISN generation on Ascend MAX (fwd)
From: marcs () ZNEP COM (Marc Slemko)
Date: Sat, 11 Oct 1997 20:16:50 -0600
For those that don't know, the MAX is Ascend's most popular WAN dialup server that is widely used among mid-sized ISPs. ---------- Forwarded message ---------- Date: Sat, 11 Oct 1997 20:12:53 -0600 (MDT) From: Marc Slemko <marcs () znep com> To: ascend-users () ascend com Subject: _very_ poor ISN generation on Ascend MAX I decided to take a look at the ISN (sequence number) generation on the MAX. I expected to, at the very least, have to take a little effort to try to fit it into an two variable linear equation. Boy was I suprised: time isn difference ========= ========== ========== 17.979213 1024896036 19.928152 1025024036 128000 21.848087 1025152036 128000 23.648915 1025280036 128000 25.221257 1025408036 128000 26.750434 1025536036 128000 28.230257 1025664036 128000 29.692895 1025792036 128000 31.172050 1025920036 128000 32.534981 1026048036 128000 33.955213 1026176036 128000 35.424979 1026304036 128000 36.856233 1026432036 128000 38.295180 1026560036 128000 That is pathetic. In certain limited situations, this renders packet filtering useless WRT connections to the MAX itself. While it presents no risk to traffic passing through the MAX, it does potentially expose connections to (and actually, also connections being made from) the MAX. Note that this violates section 4.2.2.9 of RFC-1122 in addition to simply being a stupid thing to do from a security standpoint. There must be half a dozen freely available examples of how to do this in a TCP stack. The method suggested in RFC-793 is inadequate for obvious reasons, but even it is 100 times better than this. I will be submitting a bug report to Ascend about this, but don't expect to get much response. "Oh, you want your MAX to conform to Internet standards? Well, that would be a feature, you need to submit a feature request". We shall see.
Current thread:
- Re: L0pht Advisory: IMAP4rev1 imapd server, (continued)
- Re: L0pht Advisory: IMAP4rev1 imapd server Marc Slemko (Oct 08)
- SNMP Insecurity Aleph One (Oct 08)
- Malicious Linux modules Runar Jensen (Oct 08)
- Re: L0pht Advisory: IMAP4rev1 imapd server Casper Dik (Oct 09)
- Security flaw in PGPverify of INN Lutz Donnerhacke (Oct 09)
- Re: L0pht Advisory: IMAP4rev1 imapd server Kragen Sitaker (Oct 09)
- Security flaw in Count.cgi (wwwcount) Razvan Dragomirescu (Oct 10)
- Huge security holes in Microsoft FP98 server extensions for Apache Marc Slemko (Oct 11)
- Re: Huge security holes in Microsoft FP98 server extensions for Aleph One (Oct 11)
- DOS PC FTP SERVER Efrain Torres Mejia (Oct 11)
- _very_ poor ISN generation on Ascend MAX (fwd) Marc Slemko (Oct 11)
- Re: L0pht Advisory: IMAP4rev1 imapd server Marc Slemko (Oct 08)
- Another way to exploit local classes in Java Andre L. Dos Santos (Oct 08)
- Re: Possible weakness in LPD protocol Oliver Friedrichs (Oct 03)
- Re: Possible weakness in LPD protocol Eivind Eklund (Oct 03)
- Re: Possible weakness in LPD protocol Doug Hughes (Oct 05)