Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: Microsoft Windows TCP/IP Timestamps Code Execution Vulnerability
From: Ivan Security <ivanchukl () gmail com>
Date: Fri, 27 Nov 2009 16:55:13 -0300

Thanks for your correct response.
Discover the problem by binary difference is quite hard and if it were
achiveable, which files should we compare?. I succesfully tested the other
vulnerabilitiy called "Microsoft Windows XP/Vista TCP/IP Orphaned
Connections Vulnerability" because i had more information. I'm testing this
issue against a Windows Vista Ultimate SP1. I could patch it and then
compare the corresponding binary files.
Following your guesses i can start to try something buggy. Thanks.



2009/11/27 <Valdis.Kletnieks () vt edu>

On Fri, 27 Nov 2009 12:27:29 -0300, Ivan Security said:

implementation in Windows 2003 Server but it seems to be very reliable. I
mean, how windows implemented it to lead to code execution?.

My guess is that there's some code in there that should have said:

if packet.hdr.type = TIMESTAMP  {
    option.callback = timestamp_handler;
    option.data = packet.hdr.timestamp_data;
} else {
    option.callback = NULL;

and some other code that did this:

if (option.callback) { *option.callback(option.data) };

but somebody forgot that else field, so .callback was random trash. Since
it was non-NULL random trash, the 'if' was true, and we end up calling
a trash pointer.  Now if you have a way to control the value of
(possibly 'option' is an malloc structure), and uou can force re-use of
the area by including multiple TCP options on a christmas-tree packet...

I can't prove that's the case here, but that's the general model for quite
few "oh fuck we called through a bad function pointer".  If it isn't that,
probably a use-after-free where some other function has re-allocated the
storage and done the fandango on the bits.

Binary diffing?. Stop spamming.

Suggesting doing a binary diff at this point wouldn't be spamming at all -
would tell you *exactly* where the missing 'else foo=NULL' was. The fact
that we don't have W2003 servers falling over left right and center would
indicate that it's probably some odd corner case involving multiple TCP
option fields and other similar (a bad multiply-nested
else/elseif/then/else', nested case statements, etc.  And at that point,
you're going to need either the source or a good binary diff to see where
it went astray. :)

Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

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