Vulnerability

    Gauntlet

Affected

    NAI Gauntlet 5.0, 5.5

Description

    John Abramson found following.  In some circumstances NAI Gauntlet
    firewall  performs  Network  Address  Translation in an unexpected
    manner, causing incorrect routable  IP addresses to be  generated.
    This can  enable unprivileged  users on  the protected  network to
    (knowingly or unknowingly) generate spurious source IP addresses.

    Affected  software  is  Gauntlet  for  NT 5.0 (unpatched, and with
    hotfixes 1,2,3) and Gauntlet for  NT 5.5 (unpatched, and with  SP1
    and hotfixes  1,2,3,4), on  NT Server  4 SP4  and SP6a.   Probably
    other  Gauntlet  and  NT  revisions.   Environment  in  which this
    vulnerability  was  tested  was  protected  internal network using
    private  address  range  192.168.1.x.   Gauntlet  configured  with
    dynamic NAT on external interface to translate all 192.168.1.x  to
    a single legal  address e.g.   xxx.yyy.199.252.  Packet  screening
    rules allow ICMP  from internal to  external, with reply  allowed,
    i.e.  internal users can ping external addresses.

    Internal  user  (no  special  privileges)  on  192.168.1.10   does
    continuous pings  to (e.g.)  www.nai.com, and  receives replies as
    expected.  Internal user on 192.168.1.20 does continuous pings  to
    (e.g.) www.nai.com but  gets no replies.   Gauntlet "Active  maps"
    window   shows   that   192.168.1.10   is   correctly   mapped  to
    xxx.yyy.199.252,   but    that   192.168.1.20    is   mapped    to
    xxx.yyy.199.253.   If  further  pings  are  initiated  from  other
    systems,   they   will   be   mapped   to   xxx.yyy.199.254,  then
    xxx.yyy.199.255, then xxx.yyy.200.0 and so on.  This is  confirmed
    by  Sniffing  the  FW  external  interface  (The  mapped   address
    sometimes increments by 2 instead of 1).

    This could at least lead to DoS of systems which legitimately  own
    the second and subsequent  mapped routable addresses; maybe  there
    are worse effects.  There are probably other scenarios which  will
    trigger the problem.

Solution

    NAI were informed of this back in December 1999 (Tar#43547); their
    support people were quite helpful and said they had replicated the
    fault, and  passed it  to their  development engineers.   They are
    still working on it.

    NAI told John that their dynamic NAT works by mapping a source  IP
    address plus  TCP/UDP port  number; since  we're using  ICMP there
    are no port numbers so it doesn't work properly. . .