Subject: Re: Fwd: Re: TCP Fragment bugs
To: Heiko W.Rupp <email@example.com>
From: Rick Byers <firstname.lastname@example.org>
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: pilhuhn.de!snert!blackbush.xlink.net!fu-berlin.de!cpk-news-hub1.bbnplanet.
> From: email@example.com (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: <firstname.lastname@example.org>
> References: <email@example.com> <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 (firstname.lastname@example.org) 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 D. Robertson "My statements in this message are personal opinions
> email@example.com which may have no basis whatsoever in fact."
Rick Byers Internet Access Worldwide
firstname.lastname@example.org System Admin
University of Waterloo, Computer Science (905)714-1400