Re: Bug parsing TCP packet

[Gustavo Moreira <gmoreira () coresecurity com>]

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/