ASP.NET vulnerability CVE-2008-5100 (assembly signing bypass): is there a fix?

Question

The short version of this question is:  Is there a fix or mitigation for the ASP.NET vulnerability CVE-2008-5100, which allows attackers to bypass assembly digital signature checking?

I'll give some background.  I apologize in advance for the length; this seems to be a complex subject.

We ran a security scanner against our Windows 2008R2 website running our ASP.NET application, and the scanner claimed we were vulnerable to CVE-2008-5100.  As stated on mitre.org and many other websites, this flaw, first reported in 2008, consists of:

The strong name (SN) implementation in Microsoft .NET Framework 2.0.50727 relies on the digital signature Public Key Token embedded in the pathname of a DLL file instead of the digital signature of this file itself, which makes it easier for attackers to bypass Global Assembly Cache (GAC) and Code Access Security (CAS) protection mechanisms, aka MSRC ticket MSRC8566gs.

This seems to be an embarrassing design flaw in the implementation of the .NET Framework, allowing an attacker who has access to the target system's filesystem to substitute a malicious DLL that will inappropriately be validated as the victim's original DLL. 

This vulnerability has a CVSS score of 10.0, making it the equivalent of the worst possible vulnerability ever encountered.

The security scanning software advised:  "Update the version of ASP.NET".  However, in my extensive Googling of this topic, there's no evidence that any other version of ASP.NET is less vulnerable.  In fact, given how serious this flaw supposedly is, it's surprising that none of the websites tracking this flaw has been updated since Jan 2009.  The only relatively recent mention of a flaw like this that I could find is in Ian Picknell's blog, in which he describes a very similar unfixed flaw in the .NET Framework 3.5 SP1 (as of Feb 2010).  Also somewhat alarming is that fact that a security vendor just added this flaw to their scanner in Jan 2013.

In the interests of brevity, I will avoid a long discussion of the meanings of ASP.NET versions.  However, it appears that the scanner is keying off the HTTP header "X-AspNet-Version: 2.0.50727".  Our application emits this header because it was compiled with build flags targeting the .NET Framework 3.0.  Indeed, the application reports this version of ASP.NET even when it's run on Windows Server 2012.  If we recompile the app with a target of the .NET Framework 4, we get the header "X-AspNet-Version: 4.0.30319".  We could probably get the scanner to stop complaining by using this compiled version, but is that really changing the way that .NET checks assemblies at runtime?  I am skeptical, but I cannot find any evidence one way or the other.

I am not so concerned about the application actually being exploited, since it requires write access to system directories.  I am concerned, as is my management, about following best practices.

Thanks.

Answer 1

As far as I understand, this CVE is a dud. The strong name is basically a signature on the DLL, and the public key is identified by the "public key token", which is a SHA-1 hash of the key truncated to 64 bits. The core functionality of the "strong name" is to avoid clashes when several developers, who do not know each other, publish different DLL with the same name.

Strong names are also supposed to support a code integrity framework: a given application will reference a DLL by name, version and public key token; matching DLL will be found in the Global Assembly Cache. An evil attacker could try to load into the GAC a malicious DLL with the same name as a genuine DLL, hoping for another application (launched by another user) to load his DLL instead of the correct one. To do that, since the application contains the "public key token", the attacker will have to sign his Evil DLL with a key which matches the public key token -- and the public key token being a cryptographic hash, he cannot.

The CVE-2008-5100 is mostly about somebody noticing that signatures on DLL are actually verified when the DLL is installed in the GAC, not when it is loaded from the GAC. This makes sense: the GAC is protected from arbitrary alterations by the operating system. Thus, if the DLL was good on entry, it is still good afterwards. Or, more accurately, to modify a DLL which has been installed into the GAC, you need extensive administrative rights which make all of this moot: if you have that power, then you already own the machine in all possible ways. This explains the deafening silence of the Web about this CVE: it is a non-issue. It is like claiming that a lock which can be opened from the inside of a house is a security vulnerability, because a burglar who is already in the house could then open the door, and let... burglars come in ? See, when I use an analogy without the veil of technical jargon, the whole things becomes ridiculous.

So the report from the scanner is not appropriate. Your problem is to find the right way to shut it up. My recommendation would be to not use a "security scanner" which makes such stupid reports.

---

Now if we look at the details, there is something "suboptimal" in this "Strong Name" business; namely, the hash is truncated to 64 bits. This means that resistance to preimages is 2⁶⁴, which is high but still technologically reachable (an effort of that magnitude has been done publicly at least once)(apparently, a second effort of that kind has begun in several universities, to solve discrete log in a 128-bit elliptic curve -- to be concluded within an estimated ten years). An attacker could try to generate a public key which matches the public key token used for a specific DLL; if he succeeds, then he can make a fake DLL that will be accepted by applications, and for this he would only need "normal" access to the GAC (still not a worry if no potential attacker can open a normal user session on your machines).

Producing 2⁶⁴ RSA key pairs is expensive (not as much as you would believe because the attacker can make somewhat invalid keys, but still expensive) so I doubt this attack would be very practical, but the security margin is rather low.

Answer 2

Just wanted to add:

This vulnerability has a CVSS score of 10.0, making it the equivalent of the worst possible vulnerability ever encountered.

You definitely can't always assume that. Not all CVSS 10 vulns are equal...some are much, much more severe than others. Honestly, it's really hard to assign a flat numerical value to a vulnerability.