From owner-freebsd-stable Fri Apr 6 14:23:14 2001 Delivered-To: freebsd-stable@freebsd.org Received: from montgomery.accessunited.com.au (montgomery.accessunited.com.au [203.46.135.133]) by hub.freebsd.org (Postfix) with ESMTP id 9B67D37B422 for ; Fri, 6 Apr 2001 14:23:08 -0700 (PDT) (envelope-from phillip@accessunited.com.au) Received: from willie.accessunited.com.au (willie.accessunited.com.au [203.46.135.139]) by montgomery.accessunited.com.au (8.10.1/8.10.1) with SMTP id f36LN0N08944 for ; Sat, 7 Apr 2001 07:23:01 +1000 (EST) Message-Id: <200104062123.f36LN0N08944@montgomery.accessunited.com.au> From: "Phillip" To: "stable@freebsd.org" Date: Sat, 07 Apr 2001 07:23:05 +1100 (EDT) Reply-To: "Phillip" X-Mailer: PMMail 2.00.1500 for OS/2 Warp 4.05 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Fwd: URGENT: Serious bug in IPFilter Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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