# Thursday, 07 December 2006
« New Snapshot | Main | IKVM 0.32 rc1 »
.NET Framework 2.0 Security Hole

Yesterday I discovered a bug in the JIT that not only causes incorrect results, but also allows the type system to be circumvented, which in turn leads to the possibility of arbitrary code execution. I have a proof-of-concept that executes arbitrary x86 code from a verifiable and partially trusted C# application.

I reported the bug to Microsoft and it turns out that it was independently discovered and reported by someone else in August (but who, I believe, did not understand the security implications of the bug). The bug was subsequently fixed in September and the fix made it into the Vista release of the .NET Framework 2.0 (so if you're running Vista, you're not vulnerable.)

They tell me that a fix will be distributed via Windows Update "sometime in the next few months". If you don't want to be vulnerable in the mean time, disable running .NET code in the browser and don't run any ClickOnce applications from untrusted sources.

I will publish my proof-of-concept and analysis after the patch is released.

Thursday, 07 December 2006 07:45:59 (W. Europe Standard Time, UTC+01:00)  #    Comments [2]
Friday, 08 December 2006 09:24:05 (W. Europe Standard Time, UTC+01:00)
A couple MONTHS? Sheesh...
Monday, 05 March 2007 19:23:27 (W. Europe Standard Time, UTC+01:00)
Any news regarding the bug?
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Comment (HTML not allowed)  

Live Comment Preview