Hello!
In message to <bugtraq@securityfocus.com> sent Mon, 16 Feb 2004
09:47:28 -0800 (PST) you wrote:
JC> First of all, there is good news for those of you out
JC> there who are worried about the new ASN.1
JC> vulnerability in Microsoft operating systems. It is
JC> NOT exploitable to run arbitrary code in anything
JC> approaching a real-world scenario.
[...]
JC> The ASN.1 vulnerabilities discovered by Eeye (there
JC> were several very similar ones) resulted in a memcpy
JC> of 4GB less a few bytes (0xFFFFFFFX) bytes to the
JC> process heap. This will quickly corrupt the entire
JC> heap and hit a guard page or unpaged address and cause
JC> an unhandled exception. When this unhandled exception
JC> occurs, application and then OS exception handlers
JC> will be called in order to attempt to deal with the
JC> protection fault.
JC> These exception handlers, in virtually every Microsoft
JC> application, do NOT use the heap since it is not
JC> guaranteed to be in a consistent state. This rules out
JC> the possibility of simply causing an exception and
JC> having the exception handlers traverse the heap and
JC> cause an arbitrary memory overwrite leading to code
JC> execution.
[...]
JC> The result, quite honestly, is a non-exploitable
JC> condition. This issue is limited in scope to a denial
JC> of service vulnerability.
Well... ok... let's think about it for a while...
It's easy to realise that one occurence of construct like this:
try {
... vulnerable code here ...
}
catch {
// free allocated memory or so
return false; // this function should never throw exceptions
}
Only *one* occurence is enough to make the bug exploitable.
Yes, I know code like this should *never* be used, but it's already widely
known that such constructs can be found even in .NET Framework code which
was meant to be secure from the first day.
--
Slawomir Piotrowski
