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.