Security relevant pf bug in recent -current

[Daniel Hartmeier]

The problem described below only affects -current systems updated within a
recent, narrow time frame. 3.4-stable, 3.4-release and earlier are NOT
affected in any way.

A bug was introduced in pfctl with pfctl_parser.c CVS revision 1.188 and
has been fixed with revision 1.189.

1.188 (bug) commited Thu Jan 22 13:32:00 2004 UTC
1.189 (fix) commited Sun Jan 25 18:47:15 2004 UTC

pfctl built from the affected source revision loads rules with incorrect
address masks, yet pfctl -sr shows seemingly correct rules. Rule
evaluation will have unexpected results, rules containing specific
addresses match any address. For instance

pass in on $ext_if from 62.65.145.30 to any port ssh keep state

might match any source address, not just 62.65.145.30. Depending on
whether this is used in pass or block rules, pf will pass connections
which should be blocked or block connections which should be passed
according to the filter policy.

If you are using -current pf, please make sure you are not using pfctl
built from pfctl_parser.c 1.188, for instance with

$ head -n 1 /usr/src/sbin/pfctl/pfctl_parser.c

If this shows 1.188, you can fix the problem by updating the file to
-current and rebuilding pfctl (a rebuild of the kernel or other userland
parts is not needed). I'm not sure whether the previous snapshots
contained this, but there are new fixed snapshots already, in case you're
not building from source.

Daniel

[James Cammarata]

Hi all. My company recently underwent the first stages of a security
review by a third-party. In this first stage they gathered information
about our network via publicly accessible records and such, and did some
port scans and some other light probing to see what they could detect on
our network.

The one thing that stuck out to me was this (from their report): "remote
host does not discard TCP SYN packets that also have the FIN flag
set." This note appeared for every visible server they probed. Now, I
thought (based on the PF FAQ) that doing a scrub on incoming packets would
stop this from happening. The first line (well, 2nd really) of my pf.conf
is "scrub in all".

Is something odd going on here? All of our servers they probed are behind
the firewall, so the scrub rule is in effect for all of them. Is scrub
just cleaning the packets instead of dropping them outright?

PS. the actual first line of my pf.conf is:
# It puts the lotion on the packets... ;)

[li...@scapa.dnsalias.net]

James Cammarata wrote:
> The one thing that stuck out to me was this (from their report): "remote
> host does not discard TCP SYN packets that also have the FIN flag
> set." This note appeared for every visible server they probed. Now, I

scrub removes ambiguities, in this case the FIN flag. The servers they
probed never saw the SYN,FIN packets, but since those packets didn't get
dropped either, you/they go this false positive. To confirm the
scrubbing (just to be sure), you could run a tcpdump behind the firewall
and try to get SF packets through it.

Moritz

[Dom De Vitto]

You might want to ask the company:
"How could this impact my company profits?"

Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. 07855 805 271
http://www.devitto.com mailto:d...@devitto.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[Per-Olov Sjöholm]

Read the old posting ( just a few days old) from me with the answer from
Daniel Hartmeier.

The subject of that posting was "Re: packets with SYN and FIN set not
discarded!"

I think as said that it's a false positive as scrub removed the FIN from
the packet. And then the pass rule with the S/SA ( I assume) matches (as
the FIN is gone).
Daniel says in the reply the scanner can only see what is sent and what
came back in the reply and traw the wrong conclusions.

I Assume that a pass rule with S/SAF instead of S/SA will avoid the false
positive but will not change anything.

Regards
/Per-Olov