Bug 22238

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

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
----------------------------------------------------------------------

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
----------------------------------------------------------------------

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

Comment 5 Brian Somers 2000-10-31 23:03:27 UTC

State Changed
From-To: open->closed

With ``nat deny_incoming'', ppp now drops incoming connections (as well as 
IP packets unrecognised by libalias !) in -current, RELENG_4 and RELENG_3.