7

Signing with a strong name (keypair stored in a .snk file) is (among other uses) meant to protect against forging assemblies.

For example: I ship my assembly signed with a strong name, then some other developer uses my assembly and so his assembly now contains a reference to mine, mentioning the public key of my keypair. Some user installs that developer assembly and my assembly and happily uses that developer's code. If anyone else tries to produce an assembly that looks like a version of mine and convince the user that it's an "update worth installing" that forged assembly won't load because I control my keypair and that forged assembly is not signed with the same keypair. Okay, cool.

But what prevents a malicious party from forging both my assembly and that dependent assembly of the other developer and "shipping" them both? They grab my assembly and that developer's assembly, tamper both, sign the forged version of my assembly with whatever key, then add a reference to it into the forged version of the dependent assembly, sign it too and then ship both. I mean maliciously "shipping" two assemblies should not be much harder than "shipping" one assembly.

How does signing with strong names protect against forging multiple assemblies?

Community
  • 1
  • 1
sharptooth
  • 167,383
  • 100
  • 513
  • 979
  • Well, strong-name that assembly too. Keep pulling that string and you'll end up at the EXE. If the attacker can replace that too then there's no point left in using strong names. – Hans Passant Feb 01 '11 at 09:02
  • @Hans Passant: I guess you're right. Could you please add this as an answer? – sharptooth Feb 01 '11 at 09:20

2 Answers2

6

Strong naming an assembly is really not meant to protect the signed assembly. It is to protect the other assembly that is loading the signed assembly.

For example, if an EXE is trusted and wants to load a known DLL from a known location (such as the GAC, a network share, the internet, etc.) it can do so using a strong name with some level of confidence that the assembly has not been tampered with.

But, if the whole set of assemblies is disassembled then re-assembled and re-signed, then yes, you're right they could just re-write the lines of code that load the rest of the assemblies such that it loads them with the new (fake) key.

But this kind of tampering would be evident. In other words, the strong name signing provides clear evidence of tampering, but doesn't prevent it in all cases. Add to that the fact that a local admin can disable strong name verification altogether (for "development" purposes) and it's obvious that strong name signing is not a bulletproof security mechanism.

Same goes for Authenticode and driver signing though. We've all seen a product out there that instructs users to "ignore the security warning". That's basically what the EXE would be doing if strong name verification were disabled or the entire set of assemblies had their signatures stripped - it would be ignoring the warning.

Josh
  • 68,005
  • 14
  • 144
  • 156
1

Strong Naming is all about, well ... "naming". I quote from here: Using Strong Name Signatures

"Strong names offer a powerful mechanism for giving .NET Framework assemblies unique identities."

That's all what you'll ever get from this mechanism. It means I can forge your assembly and all assemblies it references, but I will not be able to pretend "you did it". I will not be able to pretend you are the publisher of these assemblies.

Simon Mourier
  • 132,049
  • 21
  • 248
  • 298
  • The problem I see is that that whole infrastructure doesn't include publishing the public key. Suppose I download an assembly and want to find out whether its from you. How do I do that? – sharptooth Feb 01 '11 at 07:51
  • @sharptooh - There are some things you can do with the new ICLRStrongName interface (http://msdn.microsoft.com/en-us/library/dd409349.aspx), for example StrongNameCompareAssemblies, but if you add that kind of checks in your app, the calls can be forged too :-) – Simon Mourier Feb 01 '11 at 08:01
  • Yes, exactly, and the problem is there's no central way where you could have published your public key. That's because the whole mechanism is not for verifying that the assembly is from you - it's only for verifying that all subsequent versions are from the same publisher as the initial version. – sharptooth Feb 01 '11 at 08:11
  • @sharptooth - Prior to .NET 4, you could use the StrongNameMembershipCondition. Since .NET 4 changes the way all policy work, I'm not sure it's still an option. – Simon Mourier Feb 01 '11 at 08:20