Today we have released MS11-044 to address CVE-2011-1271, a remote code execution vulnerability in the .NET framework. Here we would like to provide more technical information about this vulnerability and why we believe this issue to be unlikely to be exploited.

This root cause of CVE-2011-1271 is that there was a bug in the JIT compiler which would cause it to mistakenly determine that a given object is always null (or non-null) and would omit certain checks.

For example:

                                     if ((value == null || value == new string[0]) == false)
00000027  test        esi,esi               ; value == null?
00000029  je          00000075 
0000002b  xor         edx,edx               ; new string[0]
0000002d  mov         ecx,6D913BD2h 
00000032  call        FFD20BC8 
00000037  cmp         eax,esi               ; value == new string[0]?
00000039  je          00000075 
                    Console.WriteLine("Post-check Value is: " + value);
0000003b  mov         ecx,dword ptr ds:[03532090h]  ; "Post-check value is: "
00000041  xor         edx,edx               ; Wrong here.
00000043  call        6D70B7E8              ; String.Concat()
00000048  mov         esi,eax               ; 
0000004a  call        6D72BE08              ; get Console.Out
0000004f  mov         ecx,eax 
00000051  mov         edx,esi 
00000053  mov         eax,dword ptr [ecx] 
00000055  call        dword ptr [eax+000000D8h]     ; Console.WriteLine()

At offset 0x41, the optimizer has incorrectly concluded that value will always be null so it directly passes a null to String.Concat().

For CVE-2011-1271, the JIT compiler can introduce a logic flaw when running C# or IL code sequences very similar to those describe above. Depending on the .NET application’s business logic, if the NULL check (or non-NULL check) is used to make a security decision, for example the check of certain credentials, and if the attacker controlled data may leverage directly or indirectly this missing logic and gain advantages based on this, then there is a possibility of remote code execution.  However, we do not believe this to be a common case for the majority of deployed .NET applications.

Special thanks to Reid Borsuk in .NET team.

Fermin Serna and Chengyun Chu, MSRC Engineering