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: <132359.1259338125@turing-police.cc.vt.edu>
Date: Fri, 27 Nov 2009 11:08:45 -0500
From: Valdis.Kletnieks@...edu
To: Ivan Security <ivanchukl@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Microsoft Windows TCP/IP Timestamps Code
	Execution Vulnerability

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 "application/pgp-signature" 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/