Packet validity checking patch by Kris

[Fyodor <fyodor () insecure org>]

Kris wrote an excellent svn log entry for his packet validity patch
which he applied on June 30, but I don't think he ever sent all the
details to nmap-dev.  Since other folks might find them interesting,
and since I want to link to them from the CHANGELOG, here they are:

r8541 | kris | 2008-06-30 16:55:19 -0700 (Mon, 30 Jun 2008) | 29 lines
Changed paths:
   M /nmap/idle_scan.cc
   M /nmap/osscan2.cc
   M /nmap/scan_engine.cc
   M /nmap/tcpip.cc
   M /nmap/tcpip.h
   M /nmap/traceroute.cc

Adding packet validity checking to readip_pcap() so the caller can assume the
packet is OK from the get-go rather than running basic checks of it's own.

In a nutshell this patch checks to make sure:

1) there is enough room for an IP header in the amount of bytes read
2) the IP version number is correct
3) the IP length fields are at least as big as the standard header
4) the IP packet received isn't a fragment, or is the initial fragment
5) that next level headers seem reasonable

For TCP, this checks that there is enough room for the header in the number
of bytes read, and that any option lengths are correct.  The options checked
are MSS, WScale, SackOK, Sack, and Timestamp.

This also fixes a bug I discovered while testing.  Since the Ethernet CRC
(and other datalink-layer data) could be read and counted, it was being
returned that there was more IP packet than there really was.  This didn't
cause an overrun of the buffer or anything, just that garbage data could have
easily been read instead of real packet data.  Now, if validity is checked for
and the number of total bytes read is larger than the IP's length, the length
is set to the IP header's total length field.

This seems to work great after doing what testing I could.  It's been out on
nmap-dev for a couple of weeks without any bad reports (none at all for that
matter).  I reviewed this patch again before committing and it looks good as
well.




_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org