Vulnerability

    ppp

Affected

    FreeBSD 3.5, 3.5.1 prior to the 2000-10-30, 4.1, 4.1.1 prior to the  2000-10-30

Description

    Following is based on a FreeBSD Sec Advisory FreeBSD-SA-00:70  and
    it was  originally found  by Robin  Melville.   The ppp(8) utility
    includes network address translation functionality for translating
    between public and private IP address ranges.  It uses the libalias
    library to perform translation services.

    The "nat  deny_incoming" command  is documented  as "refusing  all
    incoming connections" and is commonly used as a simple  "firewall"
    to  prevent  outside  users  from  connecting  to  services on the
    internal  network.   However  the  behaviour  of  the ppp code was
    changed  in  the  4.x  and  3.x  branches  prior to the release of
    FreeBSD 4.1  and 3.5  (on 2000-06-05  and 2000-06-03 respectively)
    to allow  passing of  packets which  are not  understood, such  as
    IPSEC  packets  and  other  IP  protocol  traffic  not  explicitly
    recognised by the code as being an "incoming connection  attempt".
    While this was  arguably incorrect behaviour  in itself, the  code
    also   incorrectly   allowed   through   ALL   incoming   traffic,
    effectively turning "deny_incoming" into a no-op.

    Thus, users who are  using the deny_incoming functionality  in the
    expectation that it  provides a "deny  by default" firewall  which
    only allows through  packets known to  be part of  an existing NAT
    session,  are  in  fact  allowing  other  types  of unsolicited IP
    traffic into their internal network.

    The behaviour of ppp was corrected to only allow incoming  packets
    which are known to be part of a valid NAT session, which gives the
    desired packet filtering behaviour in the general case.   Outgoing
    IP  traffic  which  is  not  understood  by  libalias  (such as an
    outgoing IPSEC packet part of a  VPN) will cause a NAT session  to
    be  established  which  will  allow  incoming  packets  with   the
    corresponding  source  and  destination  IP addresses and protocol
    number to pass, but all others to be denied.

    This behaviour may  be sufficient for  the security needs  of many
    users, although users with  advanced filtering or security  policy
    requirements are advised to use a more configurable packet  filter
    such as those provided by  ipfw(8) or ipf(8) which can  meet their
    needs.

    The following released versions  of FreeBSD are the  only releases
    vulnerable to this problem: 3.5, 3.5.1, 4.1, 4.1.1.  It was  fixed
    in  the  4.1.1-STABLE  branch  prior  to  the  release  of FreeBSD
    4.2-RELEASE.

    Remote users can  cause incoming traffic  which is not  part of an
    existing NAT session to pass the NAT gateway, which may constitute
    a breach of security policy.

Solution

    Use a  true packet  filter such  as ipfw(8)  or ipf(8)  on the PPP
    gateway  to  deny  incoming  traffic  according  to  the   desired
    security policy.

    Patch:

        ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:70/ppp.patch
        ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:70/ppp.patch.asc

    Source:

    Index: nat_cmd.c
    ===================================================================
    RCS file: /mnt/ncvs/src/usr.sbin/ppp/nat_cmd.c,v
    retrieving revision 1.49
    retrieving revision 1.50
    diff -u -r1.49 -r1.50
    --- nat_cmd.c	2000/07/11 22:11:31	1.49
    +++ nat_cmd.c	2000/10/30 18:02:01	1.50
    @@ -421,7 +421,11 @@
           break;
    
         case PKT_ALIAS_IGNORED:
    -      if (log_IsKept(LogTCPIP)) {
    +      if (PacketAliasSetMode(0, 0) & PKT_ALIAS_DENY_INCOMING) {
    +        log_Printf(LogTCPIP, "NAT engine denied data:\n");
    +        m_freem(bp);
    +        bp = NULL;
    +      } else if (log_IsKept(LogTCPIP)) {
             log_Printf(LogTCPIP, "NAT engine ignored data:\n");
             PacketCheck(bundle, MBUF_CTOP(bp), bp->m_len, NULL, NULL, NULL);
           }