Bugtraq mailing list archives
Re: remote memory reading through tcp/icmp
From: Casper Dik <Casper.Dik () Sun COM>
Date: Thu, 31 Jan 2002 10:35:40 +0100
And then we modify nmap(1) (Around line 687) so it only transmits the first fragment out of a fragmented scan. This will illict a ICMP TTL Exceeded message. Due to Linux including a lot more of the packet than most other OS's, we have around 20 bytes to read. From memory, Solaris includes a little bit extra on ICMP messages.
I don't believe Solaris is vulnerable to this attack; while it does return some bytes from the packet that caused an ICMP message, it does so by prepending an ICMP header and truncating the packet if it is longer than the (configurable) number of bytes it wants to send back. It returns the same STREAMs message buffer which does not contain holes or uninitialized data. (A quick check is reboot your Solaris system with "set kmem_flags = 0xf" in /etc/system; this enabled the kernel memory debugger and causes all uninitialized data reads to 0xbaddcafe; if it reads from previously freememory you'll find 0xdeadbeef; if you read from a buffer's readzone you'll get 0xfeedface. An packet returning bad data would most likely contain 0xbaddcafe. Casper
Current thread:
- remote memory reading through tcp/icmp Andrew Griffiths (Jan 20)
- Re: remote memory reading through tcp/icmp Fyodor (Jan 21)
- RE: remote memory reading through tcp/icmp David LeBlanc (Jan 22)
- Re: remote memory reading through tcp/icmp Casper Dik (Jan 31)
- <Possible follow-ups>
- Re: remote memory reading through tcp/icmp Andi Kleen (Jan 22)
- Re: remote memory reading through tcp/icmp (linux) Martin Mačok (Jan 22)
- RE: remote memory reading through tcp/icmp Michael Wojcik (Jan 22)