Question

I’ve reviewed the .NET Strong Name process a few times and think I’m comfortable with it, but I’m left with what I think is a security gap:

I’m working on a system whereby we store serialized .NET assemblies in our MS SQL database. They are read by a public-facing web application that deserializes and caches them. This is done to allow remote addition of new plugins without having to redeploy the web app.

I have some concerns about author verification, however. Both the web app and the plugin assemblies have strong names using the same public-private key. In that way I’m guaranteed that the plugins can’t be tampered with, but I see one scenario in which a malicious user could execute their own code:

1. The user implements an assembly that implements the interface our plugins are using (this is nontrivial since the plugins are not distributed – we create them internally).
2. The user gives this assembly a strong name of their own
3. The user manages to inject their assembly into the appropriate table in our database
4. The web application loads this assembly and instantiates the constructor for the interface the malicious user implemented – it is now executing their code

It’s my understanding that the .NET Framework will only check that an assembly has a strong name and that it hasn’t been tampered with – it doesn’t say anything about verification of the author.

Thus, the last piece of my puzzle is to somehow verify that the signature in an assembly is in fact our own. Am I missing some fundamental piece that’s already been addressed, or is strong naming not designed to handle this case? If so, can anyone suggest how to address this problem?

[Edit]
Thanks Khalid! My problem was that one of my test plugins was signed using a test key – I had since regenerated it (don’t ask) and applied it to the other assemblies but missed that one. As a result, I thought that GetPublicKey() was returning inconsistent values!

Code snippet for anyone who is following this path:

private bool ValidateAssembly( byte[] deserializedAssembly ){
   byte[] ourKey = Assembly.GetExecutingAssembly().GetName().GetPublicKey();
   for (int i=0; i < deserializedAssembly.Length; i++){
      if ( deserializedAssembly[i] != outKey[i] )
         return false;
    }
    return true;
}

(Any error handling or non-public key checks removed for clarity)

Note this works as long as the executing assembly (web app) and plugins are signed using the same key. This works for us internally but if your plugin API is public you’d need a different way of managing trust.

Answer 1

Your attack sounds plausable until I read aloud this sentence.

The user manages to inject their assembly into the appropriate table in our database

If the hacker has access to your database, I think that is a bigger problem than worrying about the code he is going to be executing. But anyways, below is some code to get the public key of the assembly you might load. You can check it against your keys and make sure it is not some other signature.

AssemblyName asmName = asm.GetName();
byte[] key = asmName.GetPublicKey();
bool isSignedAsm = key.Length > 0;
Console.WriteLine( "IsSignedAssembly={0}", isSignedAsm )

The AssemblyName class should give you enough information to decipher whether your signature matches the key you provide people.

Now if a hacker has your keys (public/private) then he’s working from the inside, and that is a bigger problem.