Can anyone check weather NetBSD is/will be vulnerable to this?

If 1.3_a is, then this also would need to be fixed before.


Path: pilhuhn.de!snert!blackbush.xlink.net!fu-berlin.de!cpk-news-hub1.bbnplanet.
 com!news.bbnplanet.com!europa.clark.net!209.70.91.68!news.clark.net!not-for-mai
 l
From: proberts@clark.net (Paul D. Robertson)
Newsgroups: comp.security.firewalls
Subject: Re: TCP Fragment bugs
Date: 16 Nov 1997 18:50:57 GMT
Organization: Clark Internet Services, Inc., Ellicott City, MD USA
Lines: 40
Message-ID: <64nfah$m26@clarknet.clark.net>
References: <64j43n$56u@clarknet.clark.net> <346E54A9.6A44@cyberus.ca>
NNTP-Posting-Host: explorer.clark.net
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Xref: pilhuhn.de comp.security.firewalls:4349

James C. Grant (no.spam@cyberus.ca) is rumored to have uttered :
: Can anyone point be toward the exploit code or specify
: how this attack works?

The description from BUGTRAQ:

   If we find that the current fragment's offset is inside the end of a  
   previous fragment (overlap), we need to (try) to align it correctly.
   Well, this is fine and good, unless the current fragment happens to NOT
   contain enough data to cover the realigning.  In that case, `offset`
   will end up being larger than `end`.  These two values are passed to
   `ip_frag_create()` where the length of the fragment data is computed.

Basicly, end - offset ends up being negative, and the resulting memory
copy kills the box.  Unpatched Linux will fail at 2 packets, NT/95 seems
to want 10-15. 

: ConSeal PC FIREWALL intercepts packets (95 now, NT real soon)
: and I would like to catch this attack in the firewall, if possible.

You'd have to maintain state informtaion for all fragmented packets in a
TCP stream until the subsequent fragment is recieved, then compare the
offset start address with the length of the previous packet.

This is probably not stoppable without a stateful packet filter, and even
then I'd think it would be rather trivial to DoS attack the filter by
sending very large fragments.  It's much better fixed at the stack, or 
by using a proxy which isn't vulnerable.  The Linux fix is one line of
code in the fragment reassembly routine.  A larger fix in circulation adds
some printk's for logging that the attack has been attempted.

'Personal firewalls' really don't address these types of issues well.
In this case, having an invulnerable proxy server, or fixing a vulnerable
proxy server as quickly as possible makes the most sense.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts@clark.net      which may have no basis whatsoever in fact."
                                                                     PSB#9280