COMMAND

    Livingston Portmaster

SYSTEMS AFFECTED

    Systems running Livingston Portmaster

PROBLEM

    Emmanuel Tychon found following.   Making some hacks with  Initial
    Sequence  Numbers  (ISN),  he  found  something  really strange on
    Livingston Portmasters routers (running ComOS). It seems that  the
    ISN is always 127.

    This is  really annoying,  because this  is really  a big security
    hole (think about IP-Blind Spoofing), and more formally, it do not
    comply with RFC793.  RFC793 says:

        To  avoid  confusion  we   must  prevent  segments  from   one
        incarnation of  a connection  from being  used while  the same
        sequence numbers may still be  present in the network from  an
        earlier incarnation.   We want to  assure this, even  if a TCP
        crashes and loses all knowledge of the sequence numbers it has
        been  using.   When  new  connections  are created, an initial
        sequence number  (ISN) generator  is employed  which selects a
        new  32  bit  ISN.   The  generator  is  bound  to a (possibly
        fictitious) 32 bit  clock whose low  order bit is  incremented
        roughly  every   4  microseconds.    Thus,   the  ISN   cycles
        approximately every 4.55 hours.  Since we assume that segments
        will stay  in the  network no  more than  the Maximum  Segment
        Lifetime (MSL) and that the MSL is less than 4.55 hours we can
        reasonably assume that ISN's will be unique.

    You can see it even with a simple tcpdump, like this:

        23:30:34.271212 ns.4965 > router1.be.telnet: S 873747771:873747771(0)
        23:30:36.901212 router1.telnet > ns.4965: S 127:127(0)
        23:30:36.901212 ns.4965 > router1.telnet: . ack 1
        23:30:41.501212 router1.telnet > ns.4965: . ack 31
        ...

    ["ns" is connecting on  "router1". Unused things has  been removed
    from tcpdump output]

SOLUTION

    Let's hope this feature gets changed soon.  Nothing yet.