bugtraq - Re: Misinformation in Security Advisories (ASN.1)

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] [day] [month] [year] [list]

Date: Tue, 17 Feb 2004 16:10:39 +0100
From: "Slawek" <sgp@...satgp.com.pl>
To: "John Compton" <john_compton24@...oo.com>,
	<bugtraq@...urityfocus.com>
Subject: Re: Misinformation in Security Advisories (ASN.1)

Hello!
In message to <bugtraq@...urityfocus.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