URGENT: Serious bug in IPFilter (fwd)

[Attila Nagy]

A FreeBSD 4.3-RC-ben mar benne van a patch.

--------------------------------------------------------------------------
Attila Nagy                                    e-mail:  Attila.Nagy at fsn.hu
Budapest Polytechnic (BMF.HU)                   @work: +361 210 1415 (194)
H-1084 Budapest, Tavaszmezo u. 15-17.           cell.: +3630 306 6758
---------- Forwarded message ----------
Date: Sat, 7 Apr 2001 02:56:42 +1000 (EST)
From: Darren Reed <darrenr at reed.wattle.id.au>
To: ipfilter at coombs.anu.edu.au
Subject: URGENT: Serious bug in IPFilter


A *VERY* serious bug has been brought to my attention in IPFilter.

In 10 words or less, fragment caching with can let through "any" packet.
Ok, so that's 8.

Cause
=====
When matching a fragment, only srcip, dstip and IP ID# are checked and
the fragment cache is checked *before* any rules are checked.  It does
not even need to be a fragment.  Even if you block all fragments with
a rule, fragment cache entries can be created by packets that match
state information currently held.

How to disable fragment caching
===============================
In realtime, use adb or gdb or kgdb or whatever to change the variable
named "ipfr_inuse" to 1000000.  1000000 isn't important, it just needs
to be larger than IPFT_SIZE and an integer.
NOTE: there are no sysctl's on BSD systems to adjust this if securelevel
      is > 0.

New version details with fix
============================
IP Filter 3.2.*
Email me (nobody should be using this now :*)
IP Filter 3.3.22
ftp://coombs.anu.edu.au/pub/net/ip-filter/ip_fil3.3.22.tar.gz
ftp://coombs.anu.edu.au/pub/net/ip-filter/patch-3.3.22.gz
http://coombs.anu.edu.au/~avalon/ip_fil3.3.22.tar.gz
http://coombs.anu.edu.au/~avalon/patch-3.3.22.gz
IP Filter 3.4.17
ftp://coombs.anu.edu.au/pub/net/ip-filter/ip_fil3.4.17.tar.gz
ftp://coombs.anu.edu.au/pub/net/ip-filter/patch-3.4.17.gz
http://coombs.anu.edu.au/~avalon/ip_fil3.4.17.tar.gz
http://coombs.anu.edu.au/~avalon/patch-3.4.17.gz

Frag Patches
============
One attachment each for 3.3.21 and 3.4.16.  These patches do not contain
changes for NAT code to make the fragment cache selective (see below),
just stop packets which aren't meant to match from matching.  You are
much better off updating the whole rev step if you can.

How to enable it in new versions
================================
Enable a security hole you say ?  You will need to have
"keep state keep frags" in your rule, not just "keep state".
That is rules with just "keep state" will no longer create
fragment cache enties (as happens now).

Remaining Issues
================
1. There is an automatic frgament cache used by NAT which is now disabled
by default and requires "frag" to be inserted into a NAT rule in order
for it to function.

2. Any and all packets which are fragments and match the required tuple
(being srcip, dstip, ipid) will be let through so long as the frag cache
entry remains.

3. Use of "keep frags" with "keep state" means fragment cache entries
can be created by packets going in *either* direction.  Nothing will
get added (now) to the fragment cache without being explicitly allowed
by a rule (IPF or NAT).

Why not reassemble fragmented packets?
======================================
Because it is *really bad* for a router to do this.  I run TCP/IP over a
fibre channel interface which has an MTU of 65280.  I *cannot* even send
full size packets over it without them being fragmented due to buffer size
problems so I'm not going to even think about defragmentation issues!  I
don't care who does it, if you've done your networking 101, you know why
routers (i.e. firewalls) do *NOT* defragment packets.

Darren

How to exploit?  Something will end up on bugtraq but so far, what I've
seen isn't a complete exploit of the problem.