From nobody@FreeBSD.org  Sun May 20 12:35:17 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id B433F37B424
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 20 May 2001 12:35:17 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f4KJZH926168;
	Sun, 20 May 2001 12:35:17 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200105201935.f4KJZH926168@freefall.freebsd.org>
Date: Sun, 20 May 2001 12:35:17 -0700 (PDT)
From: jsnader@ix.netcom.com
To: freebsd-gnats-submit@FreeBSD.org
Subject: Interactive use of user PPP and ipfilter can be insecure
X-Send-Pr-Version: www-1.0

>Number:         27474
>Category:       kern
>Synopsis:       [ipfilter] [ppp] Interactive use of user PPP and ipfilter can be insecure
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    cy
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun May 20 12:40:01 PDT 2001
>Closed-Date:    
>Last-Modified:  Wed Jul 03 05:09:07 UTC 2013
>Originator:     Jon Snader
>Release:        4.2 Release
>Organization:
>Environment:
FreeBSD bsd.jcs.com 4.2-RELEASE FreeBSD 4.2-RELEASE #2: Tue May 15 18:27:34 EDT 2001     jcs@bsd.jcs.com:/usr/src/sys/compile/JCS  i386

>Description:
This is a follow up on problems kern/17494 and kern/25344.  When using
user PPP with ipfilter, the filter rules are not automatically applied
to tunN.  This happens because tunN is not created until it is used
(kern/17494), and therefore does not exist when network_pass1 from
rc.network is run.  As noted in kern/25344, it is necessary to first
start PPP and then reapply the rules with ifp -Fa -f /etc/ipf.rules.
Just using ipf -y did not completely work for me (only some of the rules
seem to be applied, and in any event it does not help *until* PPP is
run, so adding ipf -y to the end of rc.network as suggested in
kern/25344 will not work if the user is starting PPP interactively from
the command line.

The most serious aspect of this problem is that the user is given no
indication of a problem.  Even if the user checks the rules right after
boot with ipf -io, the rules appear to be installed.  Running ipf -V
indicates that the filter is running.  It is only by starting PPP,
running something that invokes one of the rules, and checking with
ipf -hio that the user discovers the firewall in completely open.

I was surprised that no security bulletin was issued for this problem,
and I urge that one be issued to alert PPP/ipfilter users that they may
be running an open system.

As a side remark, putting the ipf -Fa -f /etc/ipf.rules in the
ppp.linkup file does not work if PPP was not started by root.
>How-To-Repeat:
Enable ipfilter in rc.conf, and reboot.  Start PPP and check the rules
with ipf -io and ipf -V.  Use the network in a way that should cause
one of the rules to be invoked.  Check with ipf -hio and observe that
the rule was not invoked.  Reload the rules with
ipf -Fa -f /etc/ipf.rules.  Again use the network in a way that will
cause one of the rules to be invoked, check with ipf -hio and observe
that the rules are now being applied.
>Fix:
Either manually reload the rules after starting PPP for the first time
or put the reload in /etc/ppp/ppp.linkup *and* start PPP as root.  This
means you should probably remove ``allow user'' from ppp.conf.

It is only necessary to reload the rules once after PPP has run.  They
will then be active on subsequent runs (until a reboot, of course).
>Release-Note:
>Audit-Trail:

From: Janet Sullivan <eliyanah@redrivernet.com>
To: jsnader@ix.netcom.com, freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/27474: Interactive use of user PPP and ipfilter can be insecure
Date: Sun, 20 May 2001 15:20:12 -0700

 > >Fix:
 > Either manually reload the rules after starting PPP for the first time
 > or put the reload in /etc/ppp/ppp.linkup *and* start PPP as root.  This
 > means you should probably remove ``allow user'' from ppp.conf.
 > 
 > It is only necessary to reload the rules once after PPP has run.  They
 > will then be active on subsequent runs (until a reboot, of course).
 
 The fix I use is to edit rc.network so the entire "start user PPP"
 section is between the "Set host name if not already set" and "establish
 ipf ruleset" sections.  After doing that everything works fine, no
 manual reloads required.

From: Brian Somers <brian@Awfulhak.org>
To: jsnader@ix.netcom.com
Cc: freebsd-gnats-submit@FreeBSD.ORG, brian@Awfulhak.org
Subject: Re: kern/27474: Interactive use of user PPP and ipfilter can be insecure 
Date: Mon, 21 May 2001 12:00:27 +0100

 > >Number:         27474
 > >Category:       kern
 > >Synopsis:       Interactive use of user PPP and ipfilter can be insecure
 
 I think that users of ppp with any sort of ipf or ipfw stuff should 
 be very careful if they're not running with a ``-unit N'' command 
 line as the only way to get things right is to install the rules from 
 either ppp.conf or ppp.linkup using the INTERFACE macro (which of 
 course requires root invocation as ppp invokes commands as the 
 real user for security reasons).
 
 For people running ``ppp -unit 100 ...'' (for example), the best way 
 to get things to work is to ensure that the interface is made 
 available before ipf/ipfw are run with something like
 
 kldload tun
 touch /dev/tun100
 
 This can probably be done from /etc/start_if.tun100 after adding 
 tun100 to the $network_interfaces variable in rc.conf - but I'm not 
 100% sure the startup ordering will let this work.  The alternative 
 with ipfw (given that everyone side-steps /etc/rc.firewall) is to 
 just invoke these commands at the start of your ipfw load script.  I 
 don't know about ipf (I've never used it).
 
 Of course I'll never really understand why users of ppp(8) don't just 
 use the -nat option or the ``set filter'' commands and do away with 
 ipf/ipfw....  I guess ipfw gives more flexibility, but I'm not sure 
 that ipf has anything that libalias doesn't.
 -- 
 Brian <brian@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
       <http://www.Awfulhak.org>                   <brian@[uk.]OpenBSD.org>
 Don't _EVER_ lose your sense of humour !
 
 

From: Darren Reed <darrenr@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.ORG
Cc:  
Subject: Re: kern/27474
Date: Mon, 18 Jul 2005 22:57:47 GMT

 Fixing this requires callbacks from attach/detach in sys/net/if.c
 Using ifnet_departure_event and ifnet_arrival_event would be the key here.
Responsible-Changed-From-To: freebsd-net->cy 
Responsible-Changed-By: cy 
Responsible-Changed-When: Wed Jul 3 05:08:47 UTC 2013 
Responsible-Changed-Why:  
Mine. 

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