I tried the exploit (that easily crashed NT and 95) on NetBSD 1.3_ALPHA
and 1.2.1 and neither showed any sign of having problems...
	Rick

On Mon, 17 Nov 1997, Heiko W.Rupp wrote:

> 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
> X-Newsreader: TIN [UNIX 1.3 950726BETA PL0]
> 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
> 

=========================================================================
Rick Byers                                      Internet Access Worldwide
rickb@iaw.on.ca                                		     System Admin
University of Waterloo, Computer Science                    (905)714-1400
http://www.iaw.on.ca/rickb/                         http://www.iaw.on.ca/