Date: Sat, 07 Apr 2001 07:23:05 +1100 (EDT) From: "Phillip" <phillip@accessunited.com.au> To: "stable@freebsd.org" <stable@freebsd.org> Subject: Fwd: URGENT: Serious bug in IPFilter Message-ID: <200104062123.f36LN0N08944@montgomery.accessunited.com.au>
next in thread | raw e-mail | index | archive | help
In the last few hours, the author of IPF issued this notice with some patches
for a bug. I didn't include the patch because it looks as though its been
revised. But depending on the state of play with the timetable for
4.3-RELEASE, it may be possible to include the updated version in
a later version of -RELEASE or -STABLE.
Cheers
==================BEGIN FORWARDED MESSAGE==================
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.
===================END FORWARDED MESSAGE===================
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104062123.f36LN0N08944>