Question

Trying to get my head around authenticode code-signing and strong-naming.

Am I right in thinking that if I code-sign an exe that references a few dlls (not strong named) that a malicious user could replace my DLLs and distribute the app in a way that appears as if it’s signed by me, but is running their code?

Assuming that’s true, it seems like you wouldn’t really want to sign a .NET app without strong-naming the whole thing, otherwise you’re giving people the ability to execute code under the guise of an app you wrote?

The reason I’m unsure, is that none of the articles I found online (including the MSDN doc about using SN+Authenticode) seem to mention this, and it seems like a fairly important point to understand (if I’ve understood correctly)?

Answer 1

Am I right in thinking that if I code-sign an exe that references a few dlls (not strong named) that a malicious user could replace my DLLs and distribute the app in a way that appears as if it’s signed by me, but is running their code?

Yes if the remainder of the DLLs are only signed and not strong named they can be replaced without .NET raising an exception. You could, inside the exe, verify the DLLs are signed by the same key as the exe. None of these approaches prevent someone from replacing your DLLs or the EXE.

Assuming that’s true, it seems like you wouldn’t really want to sign a .NET app without strong-naming the whole thing, otherwise you’re giving people the ability to execute code under the guise of an app you wrote?

Generally I suppose that is the ‘best practice’, but again you have not prevented anything. Once a user has the rights to change files on the local system there is not much you can do to stop them from malicious activity.

There are several obfuscation technologies that build complete .NET projects into a single exe, this might make the ‘most secure’ approach but still can tampered with.

The real question is what are you trying to prevent them from doing? I mean to say, why would someone be interested in replacing your dll? What would they hope to achieve, what is their goal? If you’re trying to prevent someone from reading sensitive information from the process you in for a long hard road of disappointment. Assume a malicious party has complete access to your source code and every piece of information used by your process, because they do. Assume they can replace all or part of your code at will, because they can.

Updated

So binding redirect will only work with assemblies strong-named with the same key, and therefore does protect you from DLLs being changed?

Correct, with the noted exception that code injection can still be done in numerous ways.

… and back to the original question, does code-signing without strong-naming kinda undermine the point of code-signing?

Not really. Code signing (not strong naming) has two distinct purposes:

1. Authentication. Verifying who the author of the software is.
2. Integrity. Verifying that the software hasn’t been tampered with since it was signed.

Often this is only authenticated and validated during installation. This is why we sign our setup.exe, to ensure that the customer has received the unmodified installer from us. They are prompted with the “Do you trust XXXX Company” and are thereby granting authorization to the authenticated/signed installer. Once installed however there is little built-in use of code signing by the OS (except for drivers and some other obscure cases).

Strong Naming on the other had has a completely different purpose for it’s existence. It’s entirely focused on ‘integrity’ of the application. There is no certificate, no signing authority (CA) to verify it against, no user-displayed information for them to confirm, and nothing the OS can verify about the executable it’s going to run.

The .NET framework uses strong names for many things, all of them I loosely categorize as application integrity:

1. The contents of the dll/exe has a signed hash so that it cannot be tampered with.
2. Each reference must be strong named and verified when loading the dependency.
3. Assemblies can be registered in the GAC and publisher policies can be used.
4. Native images can be ngen’d to produce a compiled image of the assembly’s IL.

I’m sure there are other things I’m missing here, but these are primary uses I’m aware of.

Best practices for Signing and Strong-naming

• Use a signed installer
• Use a code-signed executable
• Use a strong-named executable
• Strong name all dependencies and references to them
• Code signing dependencies is not generally required*
• Consider GAC registering assemblies at install time

*Note: Code signing can be useful in some cases for a DLL, for example COM objects marked ‘safe’ and embedded into a browser should be signed and strong-named as if it were an executable. Code signing can also be useful in externally verifying dependencies without loading the assembly or reflecting it’s attributes.