Bug 27474

Summary:	[ipfilter] [ppp] Interactive use of user PPP and ipfilter can be insecure
Product:	Base System	Reporter:	jsnader <jsnader>
Component:	kern	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed Not A Bug
Severity:	Affects Only Me	CC:	cy, lwhsu
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description jsnader 2001-05-20 20:40:01 UTC

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.

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

Comment 1 eliyanah 2001-05-20 23:20:12 UTC

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

Comment 2 Brian Somers 2001-05-21 12:00:27 UTC

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

Comment 3 Darern Reed freebsd_committer

2005-07-18 23:57:47 UTC

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.

Comment 4 Cy Schubert freebsd_committer

2013-07-03 06:08:47 UTC

Responsible Changed
From-To: freebsd-net->cy

Mine.

Comment 5 Eitan Adler freebsd_committer

2017-12-31 07:58:37 UTC

For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped

Comment 6 Cy Schubert freebsd_committer

2020-10-30 15:56:36 UTC

The user must issue ipf -y, either manually or in their PPP script, following the creation of new tunnel NICs. (I do this in my ssh and IPsec tunnel scripts.)