Vulnerability

    ISN generation

Affected

    Ascend MAX

Description

    For those that  don't know, the  MAX is Ascend's  most popular WAN
    dialup server that is widely used among mid-sized ISPs.  It is not
    my idea to put stuff about SN on these pages, but what Marc Slemko
    found is really out of mind.

    Marc  decided  to  take  a  look  at  the  ISN  (sequence  number)
    generation on the MAX.  And results were surprise:

        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.

Solution

    Write to Ascend and ask them  for health.  In meantime, use  other
    dialup server.