Re: Misinformation in Security Advisories (ASN.1)

["Slawek" <sgp () telsatgp com pl>]

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