Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Bug parsing TCP packet
From: Gustavo Moreira <gmoreira () coresecurity com>
Date: Tue, 18 Jun 2013 15:39:12 -0300

On 17/06/2013 03:05 p.m., David Fifield wrote:
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 Security
Hi,

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
Thanks Henri and Hi David,
As far as I saw, this bug causes that more elements being added to the
"features" array in "vectorize" function, and regardless of these are
zeros, it ends with different "accurate" percentages when
"predict_values" function is called.
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault