From robmel@muffin.highwire.local  Mon Oct 23 02:25:29 2000
Return-Path: <robmel@muffin.highwire.local>
Received: from muffin.highwire.local (m916-mp1-cvx1a.not.ntl.com [213.104.43.148])
	by hub.freebsd.org (Postfix) with ESMTP id A045937B479
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 23 Oct 2000 02:25:28 -0700 (PDT)
Received: by muffin.highwire.local (Postfix, from userid 1001)
	id 2D3FA7038; Mon, 23 Oct 2000 10:25:27 +0100 (BST)
Message-Id: <20001023092527.2D3FA7038@muffin.highwire.local>
Date: Mon, 23 Oct 2000 10:25:27 +0100 (BST)
From: robmel@innotts.co.uk
Sender: robmel@muffin.highwire.local
Reply-To: robmel@innotts.co.uk, robmel@nadt.org.uk
To: FreeBSD-gnats-submit@freebsd.org
Subject: User PPP "deny_incoming" option does not deny incoming connections
X-Send-Pr-Version: 3.2

>Number:         22238
>Category:       bin
>Synopsis:       User PPP "deny_incoming" option does not deny incoming connections
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Oct 23 02:30:00 PDT 2000
>Closed-Date:    Tue Oct 31 15:03:27 PST 2000
>Last-Modified:  Tue Oct 31 15:05:23 PST 2000
>Originator:     Robin Melville
>Release:        FreeBSD 4.1.1-STABLE i386
>Organization:
Nottingham Alcohol & Drug Team
>Environment:

FreeBSD muffin.highwire.local 4.1.1-STABLE FreeBSD 4.1.1-STABLE #0: Fri Oct 20 02:59:08 BST 2000     root@muffin.highwire.local:/usr/obj/usr/src/sys/muffin  i386

>Description:

User PPP has the option to prevent any connections to be established from the
remote end. The options "nat enable yes" and "nat deny_incoming yes" should
place ppp in this state. It does not. PPP uses the libalias library which
correctly returns the status flag PKT_ALIAS_IGNORED when an incoming 
connection is attempted. However ppp does not drop the packet as advertised.

The implications of this are serious for users who believe they are behind
a one-way firewall. In fact, all their services which are not explicity
bound only to the loopback and/or internal interfaces are fully exposed on the
Internet and can be connected to. While this does not bypass any other
security which may be in place on these services it markedly increases their
ppp host's vulnerability to unauthorised access using other known or
unknown exploits.

>How-To-Repeat:

Set up PPP with "nat enable yes" and "nat deny_incoming yes". Cause ppp to
dial up/make a remote connection. Use a port scanner from elsewhere on the
Internet/remote network or attempt to connect to an internally available
service. Services are both visible and available.

>Fix:

Alter /usr/src/usr.sbin/ppp/nat_cmd.c as follows:

--- nat_cmd.c   Sun Oct 22 11:22:01 2000
+++ nat_cmd+.c  Sun Oct 22 11:53:49 2000
@@ -422,11 +422,14 @@
 
     case PKT_ALIAS_IGNORED:
       if (log_IsKept(LogTCPIP)) {
-        log_Printf(LogTCPIP, "NAT engine ignored data:\n");
+        log_Printf(LogTCPIP, "NAT engine set packet to be ignored:\n");
         PacketCheck(bundle, MBUF_CTOP(bp), bp->m_len, NULL, NULL, NULL);
       }
+      /* libalias has marked this packet to be ignored. It should be dropped */
+      m_freem(bp);
+      bp = NULL;
       break;
-
+      
     default:
       log_Printf(LogWARN, "nat_LayerPull: Dropped a packet (%d)....\n", ret);
       m_freem(bp);


>Release-Note:
>Audit-Trail:

From: Ruslan Ermilov <ru@sunbay.com>
To: robmel@innotts.co.uk
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/22238: User PPP "deny_incoming" option does not deny incoming connections
Date: Mon, 23 Oct 2000 18:33:37 +0300

 On Mon, Oct 23, 2000 at 10:25:27AM +0100, robmel@innotts.co.uk wrote:
 > 
 > User PPP has the option to prevent any connections to be established from the
 > remote end. The options "nat enable yes" and "nat deny_incoming yes" should
 > place ppp in this state. It does not. PPP uses the libalias library which
 > correctly returns the status flag PKT_ALIAS_IGNORED when an incoming 
 > connection is attempted. However ppp does not drop the packet as advertised.
 > 
 > The implications of this are serious for users who believe they are behind
 > a one-way firewall. In fact, all their services which are not explicity
 > bound only to the loopback and/or internal interfaces are fully exposed on the
 > Internet and can be connected to. While this does not bypass any other
 > security which may be in place on these services it markedly increases their
 > ppp host's vulnerability to unauthorised access using other known or
 > unknown exploits.
 > 
 We had the discussion recently with Brian Somers on this topic.
 Hopefully, we will come up with a solution shortly.
 
 -- 
 Ruslan Ermilov		Oracle Developer/DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
 

From: Robin Melville <robmel@innotts.co.uk>
To: freebsd-gnats-submit@FreeBSD.org, robmel@nadt.org.uk
Cc:  
Subject: Re: bin/22238: User PPP "deny_incoming" option does not deny
 incoming connections
Date: Tue, 24 Oct 2000 14:00:45 +0100

 I should point out that the fix I submitted above is something of a 
 kludge. Under some circumstances libalias will return 
 PKT_ALIAS_IGNORED if it doesn't understand the incoming packet. A 
 full fix should test for this.
 
 However, I have tested it with a bunch of normal traffic (http, ftp, 
 smtp, telnet, ssh, rtsp, irc dcc) and it seems to work fine.
 -- 
 ----------------------------------------------------------------------
 Robin Melville, Addiction Information Services 
 Nottingham Alcohol & Drug Team
 work: robmel@nadt.org.uk        http://www.nadt.org.uk/
 home: robmel@innotts.co.uk	http://www.innotts.co.uk/~robmel
 ----------------------------------------------------------------------
 

From: Robin Melville <robmel@innotts.co.uk>
To: Ruslan Ermilov <ru@sunbay.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG,
	security-officer@.highwire.local
Subject: Re: bin/22238: User PPP "deny_incoming" option does not deny
 incoming connections
Date: Wed, 25 Oct 2000 06:30:44 +0100

 At 6:33 pm +0300 23/10/00, Ruslan Ermilov wrote:
 >We had the discussion recently with Brian Somers on this topic.
 >Hopefully, we will come up with a solution shortly.
 
 Given that this situation has serious security implications for users 
 of this feature, isn't there a case to be made for at least a FreeBSD 
 security advisory. Or, since this code is shared across several 
 platforms, a CERT advisory?
 
 It's a little alarming that this is a known problem but users have 
 not been warned.
 
 Best wishes,
 
 Robin.
 -- 
 ----------------------------------------------------------------------
 Robin Melville, Addiction Information Services 
 Nottingham Alcohol & Drug Team
 work: robmel@nadt.org.uk        http://www.nadt.org.uk/
 home: robmel@innotts.co.uk	http://www.innotts.co.uk/~robmel
 ----------------------------------------------------------------------
 

From: Robin Melville <robmel@innotts.co.uk>
To: freebsd-gnats-submit@FreeBSD.org
Cc: Ruslan Ermilov <ru@sunbay.com>, Brian Somers <brian@FreeBSD.org>,
	robmel@nadt.org.uk, Eivind Eklund <eivind@FreeBSD.org>
Subject: Re: bin/22238: User PPP "deny_incoming" option does not deny
 incoming connections
Date: Wed, 25 Oct 2000 09:52:27 +0100

 Apologies for following up my own posts.
 
 Following comments by Ruslan Ermilov I am submitting a revised patch 
 for this issue. This fixes the hole and causes ppp(8) to have the 
 same behaviour as the natd(8) daemon in relation to the deny_incoming 
 flag. It permits packets that are scrambled or otherwise unrecognised 
 by the libalias(3) engine when deny_incoming is not set but drops 
 them if it is.
 
 The rationale for dropping scrambled or unrecognised packets as well 
 as connection attempts when deny_incoming is set is that the default 
 behaviour of a one-way firewall is to block packets which are not 
 responses to traffic originating from the interior of the firewall. 
 Since the aliasing engine is unable to confirm this for packets it 
 ignores, the safest action is to discard them.
 
 Libalias(3) returns an ambiguous result code (PKT_ALIAS_IGNORED) 
 which serves to indicate both incoming scrambled or unrecognised 
 packets as well as packets for which a connection does not exist in 
 its rewriting table when PKT_ALIAS_DENY_INCOMING is set. However, the 
 response of ppp(8) to these conditions is unambiguous. Consequently 
 it makes more sense to fix ppp(8) rather than alter the interface to 
 libalias(3) by adding an additional result code.
 
 Revised patch:
 --- nat_cmd.c   Sun Oct 22 11:22:01 2000
 +++ nat_cmd+.c  Wed Oct 25 07:59:24 2000
 @@ -421,12 +421,20 @@
         break;
 
       case PKT_ALIAS_IGNORED:
 -      if (log_IsKept(LogTCPIP)) {
 -        log_Printf(LogTCPIP, "NAT engine ignored data:\n");
 +       /* libalias(3) has ignored this packet. This may be either 
 because it does not
 +       understand it or because deny_incoming is set and no link 
 exists in the aliasing
 +       table. */
 +       if (log_IsKept(LogTCPIP)) {
 +        log_Printf(LogTCPIP, "NAT engine ignored packet:\n");
           PacketCheck(bundle, MBUF_CTOP(bp), bp->m_len, NULL, NULL, NULL);
         }
 +      /* drop the packet if deny_incoming is set */
 +      if (PacketAliasSetMode(0,0) & PKT_ALIAS_DENY_INCOMING) {
 +             m_freem(bp);
 +             bp = NULL;
 +           }
         break;
 -
 +
       default:
         log_Printf(LogWARN, "nat_LayerPull: Dropped a packet (%d)....\n", ret);
         m_freem(bp);
 
 -- 
 Robin Melville, Addiction Information Services 
 Nottingham Alcohol & Drug Team
 work: robmel@nadt.org.uk        http://www.nadt.org.uk/
 home: robmel@innotts.co.uk	http://www.innotts.co.uk/~robmel
 
State-Changed-From-To: open->closed 
State-Changed-By: brian 
State-Changed-When: Tue Oct 31 15:03:27 PST 2000 
State-Changed-Why:  
With ``nat deny_incoming'', ppp now drops incoming connections (as well as 
IP packets unrecognised by libalias !) in -current, RELENG_4 and RELENG_3. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=22238 
>Unformatted:
