Nmap Development mailing list archives
Re: Bug parsing TCP packet
From: David Fifield <david () bamsoftware com>
Date: Mon, 17 Jun 2013 11:05:47 -0700
On Sun, Jun 16, 2013 at 10:33:20PM +0200, Henri Doreau wrote:
2013/6/3 Gustavo Moreira <gmoreira () coresecurity com>:Hi guys, I am working with nmap IPv6 OS fingerprinting code and I found that when a TCP packet is padded to 32 bytes, there is a bug parsing its TCP Options. It's because the libnetutil TCPHeader::getOption function doesn't stop to iterate when a "End Of Options" option is found, so it read the last padded zero as one more TCP option. In addition, it causes that FPEngine::vectorize add more values to the "features" array, and then it affects the final calculations when liblinear::predict_values is called. I attached a .pcap so you can reproduce the bug. Regards, Gustavo Moreira Core SecurityHi, Thanks for the report and sorry for the late answer. I just wrote a super simple patch (attached) that I guess should fix the issue. David, could you have a look at the consequences on the OS FP engine?
Thanks, looks good to me. There are no consequences to the OS classifier because we don't currently have any training examples that pad TCP in this way. David Fifield _______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Bug parsing TCP packet Gustavo Moreira (Jun 03)
- Re: Bug parsing TCP packet Henri Doreau (Jun 16)
- Re: Bug parsing TCP packet David Fifield (Jun 17)
- Re: Bug parsing TCP packet Henri Doreau (Jun 17)
- Re: Bug parsing TCP packet Gustavo Moreira (Jun 20)
- Re: Bug parsing TCP packet David Fifield (Jun 17)
- Re: Bug parsing TCP packet Henri Doreau (Jun 16)