COMMAND

    FW-1

SYSTEMS AFFECTED

    Firewall-1

PROBLEM

    The Dartmouth Collage security group has uncovered a problem  with
    Firewall-1  which  could  lead  to  the protected site handing out
    more IP address info than intended.

    Under certain  nominal load  conditions (CPU  less than  40%, 200+
    active  sessions)  Firewall-1  will  begin  "leaking" packets with
    their private address information in tact.  The result is that the
    receiving site  will receive  a SYN=1  that it  will be  unable to
    respond to.  Once the client attempts a resend, the target network
    (or anyone in the middle)  can use the source port  information to
    enumerate the client's true IP address.

    Here is a Snort trace  which has been sanitized and  formatted for
    easier viewing:

        Mar  9 14:01:19 172.30.1.10:1721 ->   192.168.1.5:80 SYN **S*****
        Mar  9 14:01:48 200.200.200.5:1721 -> 192.168.1.5:80 SYN **S*****
        
        Mar  9 14:04:35 172.30.1.10:1858 ->   192.168.1.5:80 SYN **S*****
        Mar  9 14:05:05 200.200.200.5:1858 -> 192.168.1.5:80 SYN **S*****
        
        Mar  9 14:23:25 172.16.5.20:4868 ->   192.168.1.5:80 SYN **S*****
        Mar  9 14:23:51 200.200.200.5:4868 -> 192.168.1.5:80 SYN **S*****

    So the first packet goes out with the private address  information
    still in  place and  SYN=1.   When the  client does  not receive a
    reply, it retransmits the SYN=1.  Since FW-1 considers this to  be
    part of the same session, the same source port number is assigned.
    If the second packet gets translated properly (as in these traces)
    the source port info can potentially  be used to map the legal  IP
    address to the private address.

    Of course the problem  here is that a  would be bad guy  now knows
    the client's true IP address.   If enough hosts are recorded,  its
    possible that most of the internal network address space could  be
    enumerated.

    This problem  has been  noted on  Firewall-1 versions  3.0b & 4.0.
    4.1 has not  been checked but  its expected that  the same problem
    may exist.   We where  able to  reproduce the  problem on  a Nokia
    IP440 and NT.  This problem was noted on Solaris 2.6 as well,  but
    there are no data to back up the statement.

SOLUTION

    A quick fix is to apply egress filtering to the border router  and
    block all  private addressing  that attempts  to leak  though.   A
    how-to on egress can be found at:

        http://www.sans.org/y2k/egress.htm

    This should be fixed with SP5 (4.0) and SP1 (4.1).