Why does .NET not verify the BCL/CLR?

All .NET assemblies in the BCL & CLR (onwards just CLR will be used) are both strongly named and digitally signed. Digital certificates are provided to give a measure of trust that the assembly has not been tampered with or replaced. However it does not appear that .NET ever checks the digital signature (it can check the strong name as Hans pointed out).

It makes sense that checking on assembly load is flawed becaused an modified CLR could fake the answers. My thinking is that the only safe place from the perspective of .NET¹ to check is on start of the framework as part of the unmanaged code that boot straps the framework. Big downside is the performance impact.

I am looking at this from the perspective of a developer, in otherwords how do I know that my application is not being compromised by an already owned CLR², or put another way is there anyway for an application to trust the CLR?

So my question is why does .NET not verify the CLR? Is it because the performance impact or is there more to it?

1. I am focusing on .NET, it is possible to mess with Windows开发者_StackOverflow and thus break the idea but if you already own Windows you don't really need to own .NET.

2. Example of this is user inputs password into application, it is stored in a SecureString but the BCL is compromised so the attacker is now getting that info. It allows them to capture the information for something else. I realise the attacker if he could replace the CLR could put a key logger on the machine too, but that is (hopefully) detectable with a decent security tool. There is also lots of other ways to attack this, the core is how do I know if SecureString has been changed.

This was changed in .NET 3.5 SP1, intended as a startup perf improvement for apps that run in full trust to give them parity with native programs which do no such checking. Verifying the strong name is expensive and cold starts on managed programs tend to be slow due to the large number of DLLs. You can turn it back on with the .config file:

<configuration>
    <runtime>
        <bypassTrustedAppStrongNames enabled="false"/>
    </runtime>
</configuration>

Or by editing a registry key so it is in effect for all .NET programs:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"AllowStrongNameBypass"=dword:00000000

Also set the HKLM\Software\Wow6432Node key on a 64-bit machine.

They are in the GAC. Whoever can mess with the GAC is already a privileged user. Also most applications run in full-trust mode where this is irrelevant anyways. Because in a full-trust application you can use pointers, native-interop,... all of which can break verification based security.

Code verification is important in scenarios where you execute lower trust code, for example in Silverlight. In such a sandbox you only want to execute:

1. Verified safe untrusted code
2. Trusted code which is either in the GAC or signed with a key you trust.

1. Example of this is user inputs password into application, it is stored in a SecureString but the BCL is compromised so the attacker is now getting that info. It allows them to capture the information for something else. I realise the attacker if he could replace the CLR could put a key logger on the machine too, but that is (hopefully) detectable with a decent security tool.

You already have a broken security model here. There are so many ways to attack your application in this threat scenario that you don't need to care about the BCL. For example the attacker could patch the NGened or JITed code. Either to directly hook into the SecureString methods, or your input handling code. He could use a variety of key logging or message interception features which in my experience are rarely detected. He could subclass your window. You could replace your GUI entirely. He could simply replace all your assemblies on disk. Unlikely that the user would notice.

In my experience most security tools don't even care if an application installs a low level keyboard hook, which is one of the easiest ways to key-log.