Bugtraq archives for 4th quarter (Oct-Dec) 1997: _very_ poor ISN generation on Ascend MAX (fwd)
_very_ poor ISN generation on Ascend MAX (fwd)
Marc Slemko (
marcs
ZNEP.COM)
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 <marcsznep.com>
To: ascend-usersascend.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.
