问题
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)?
回答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:
- Authentication. Verifying who the author of the software is.
- 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:
- The contents of the dll/exe has a signed hash so that it cannot be tampered with.
- Each reference must be strong named and verified when loading the dependency.
- Assemblies can be registered in the GAC and publisher policies can be used.
- 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.
回答2:
Once someone can replace dll's or run code on your machine there arent that many safeguards left to you. In my case all the Dll's are code signed individually. My code refuses to download Dll's that are not signed as part of the self update. However any app running at my integrity level or higher on my system (In the case of >= Vista Windows) can still inject a dll into my exe with something like CreateRemoteThread etc (http://www.codeguru.com/Cpp/W-P/dll/article.php/c105) But again assuming someone can get foreign code into the system is the hard part. The rest is easy.
回答3:
you must also remember that Code Signing often introduces lots of pain when upgrading dll's without deploying other parts of the application.
This is why many popular libraries do not strongly name the dll's
回答4:
After being searching for same and reading many stuff. I finally can say to your question, YES, strong name for dependencies is must if you are going to digitally signing your app exe.
Assume this, if your dependencies don't have strong name. And they get replaced. Your application will load them without any problem. And user will see dialog "Verified Publisher : Your Name". While executable was untouched but dependencies got altered.
Problem is not that user but distribution of that package with altered dependencies while everyone will see your name on it.
来源：https://stackoverflow.com/questions/8566755/does-code-signing-without-strong-naming-leave-your-app-open-to-abuse