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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 17 Feb 2004 16:10:39 +0100
From: "Slawek" <>
To: "John Compton" <>,
Subject: Re: Misinformation in Security Advisories (ASN.1)

In message to <> 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

Powered by blists - more mailing lists