Damon Cortesi's blog

Musings of an entrepreneur.

Analyzing .NET Patches

| Comments

OK, so perhaps the title is a little misleading, but here’s an interesting excercise in taking a look at issues that have been patched within the .NET framework. There’s a great tool out there by Lutz Roeder called .NET Reflector. Reflector allows you to generate source code (C#, C++, ILAsm, heck even PowerShell) from .NET assemblies. This will be our primary tool for this task.

There was an advisory last month regarding some critical vulnerabilities in the .NET Framework (MS07-040). There was one in issue in particular that was quite interesting:

An information disclosure vulnerability exists in .NET Framework that could allow an attacker who successfully exploited this vulnerability to bypass the security features of an ASP.NET Web site to download the contents of any Web page.

That sounds pretty interesting, but I had yet to see many details beyond that and I was somewhat curious as to where in the code this seemingly simple issue lay. So let’s dig in.

I made a copy of my Framework in C:\WINDOWS\Microsoft.NET\Framework and then installed the relevant patch. Assuming that the issue was in System.Web.dll, I opened each version of that dll in Reflector and exported the source code. Although Reflector does include an assembly diff utility, I wasn’t able to open the two dll’s at the same time as they have the same assembly version. So I had to manually diff the source files until I came on something…”interesting”.

<font FACE="Courier New">
</font><font COLOR="#0000ff">internal static void </font><font COLOR="#000000">CheckSuspiciousPhysicalPath(</font><font COLOR="#0000ff">string </font><font COLOR="#000000">physicalPath)</font>
<font COLOR="#000000">{</font>
    <font COLOR="#0000ff">if </font><font COLOR="#000000">(((physicalPath != </font><font COLOR="#0000ff">null</font><font COLOR="#000000">) && (physicalPath.Length > </font><font COLOR="#800080">0</font><font COLOR="#000000">)) && (</font><font COLOR="#808000">Path</font><font COLOR="#000000">.GetFullPath(physicalPath) != physicalPath))</font>
    <font COLOR="#000000">{</font>
        <font COLOR="#0000ff">throw new </font><font COLOR="#808000">HttpException</font><font COLOR="#000000">(</font><font COLOR="#800080">0x194</font><font COLOR="#000000">, </font><font COLOR="#ff00ff">""</font><font COLOR="#000000">);</font>
    <font COLOR="#000000">}</font>
<font COLOR="#000000">}</font>

This CheckSuspiciousPhysicalPath didn’t exist in the previous revision of System.Web.dll and seems like it is attempting to address the issue mentioned in MS07-040. Note that CheckSuspiciousPhysicalPath compares the results of the original physicalPath variable and Path.GetFullPath(physicalPath) and GetFullPath will throw an exception if the path contains any invalid characters.

So now we have at least one potential place where an additional check for nulls is being performed. What’s left is to see if there are other locations and at the same time drop a breakpoint on this piece of code and see if we can trigger it.