Re: Microsoft Windows TCP/IP Timestamps Code Execution Vulnerability

[Ivan Security <ivanchukl () gmail com>]

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.

Regards,

Ivan.


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
> through
> a trash pointer.  Now if you have a way to control the value of
> option.callback
> (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
> a
> few "oh fuck we called through a bad function pointer".  If it isn't that,
> it's
> 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 -
> it
> 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
> 'if/then/elseif/then/if/
> 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/