Re: [Full-Disclosure] Misinformation in Security Advisories (ASN.1)

[Valdis.Kletnieks@vt.edu]

--==_Exmh_2070112410P
Content-Type: text/plain; charset=us-ascii

On Mon, 16 Feb 2004 08:42:23 PST, John Compton <john_compton24@yahoo.com> said:

> You are likely not going to see any more than the DoS exploit that has
> already come out. For those of you interested in the technical explanation of
> why, it is included below (it's honestly beyond my complete understanding).
> Most of the security researchers I've spoken to agree with this assessment and
> the information below.

Now which should I believe here:

1) Your proof of why it's not possibly exploitable when you yourself admit you don't
understand it?

2) The possibility that some clever black hat fully understands the challenges
and has found a way around it? (Say, wasn't there another exploit a while ago
that managed to work around that "exception handlers don't use the heap"
problem?)


--==_Exmh_2070112410P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFAMQiqcC3lWbTT17ARAn/SAJ9LqMAcKxFfLxLG95VbKpWLO7Q5VACgjnCk
ziTNvbtOCZeRifWZCW2/dVU=
=8+42
-----END PGP SIGNATURE-----

--==_Exmh_2070112410P--

[Anthony Saffer]

> First of all, there is good news for those of you out there who are
> worried about the new ASN.1 vulnerability in Microsoft operating
> systems. It is NOT exploitable to run arbitrary code in anything
> approaching a real-world scenario.

I have to agree with Simon here. Hackers don't deal in "real world"
scenarios but rather specialize in creating exceptional conditions that
wouldn't ever occur under normal operational circumstances. The fact remains
that, regardless of how remote the possibility of a hacker creating the
"right" circumstances on your network/system for an exploit to work, it's
unlikeness doesn't really sooth the nerves of the system admin having to
deal with a breach and recover vital data.

Anthony Saffer [CEO & Founder]
SCS Consulting Services
www.safferconsulting.com
(918) 812-5785

[first last]

John Compton john_compton24@yahoo.com wrote:
>Another possibility for remote code execution would be to trigger a
>context-switch mid-memcpy which would halt the memory copy operation
>before it hits an unpaged address. This, if possible, might leave the
>heap in a corrupted state but allow another thread to access/traverse
>the heap before the exception occurs. However, Microsoft compilers
>optimize the memcpy() function call to the REPNE MOVSD instruction. This
>makes it extremely unlikely, if not statistically impossible, to
>get a context switch at the right time before an unpaged address is
>accessed. Once again, this cannot be used to exploit this bug.

REP string instructions (eg. REP MOVS), like all other instructions, all
check for HW interrupts after each iteration is complete. It is not possible
to load ECX with FFFFFFFFh and do a REP LODSD to stop HW interrupts from
occuring until ECX is 0.

__________________________________________________ _______________
Plan your next US getaway to one of the super destinations here.
http://special.msn.com/local/hotdestinations.armx

[Slawek]

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