Subject: Re: Fwd: Re: TCP Fragment bugs
To: Heiko W.Rupp <>
From: Rick Byers <>
List: current-users
Date: 11/17/1997 13:14:21
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...

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:!snert!!!cpk-news-hub1.bbnplanet.
>  com!!!!!not-for-mai
>  l
> From: (Paul D. Robertson)
> Newsgroups:
> 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$>
> References: <64j43n$> <>
> NNTP-Posting-Host:
> 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:
> James C. Grant ( 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
>      which may have no basis whatsoever in fact."
>                                                                      PSB#9280

Rick Byers                                      Internet Access Worldwide                                		     System Admin
University of Waterloo, Computer Science                    (905)714-1400