full-disclosure - Re: Microsoft Windows TCP/IP Timestamps Code Execution Vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b7f2f5680911271155l7be962b9j5c01e53032e0574@mail.gmail.com>
Date: Fri, 27 Nov 2009 16:55:13 -0300
From: Ivan Security <ivanchukl@...il.com>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Microsoft Windows TCP/IP Timestamps Code
	Execution Vulnerability

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@...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. :)
>
>
>

Content of type "text/html" skipped

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