What's an assembly identity? - c#

(Let's assume I only have a single default appdomain for this question)
Apparently Assembly.LoadFrom() can lead to multiple assemblies of the same name, version and content to be loaded even if just their paths are different.
This seems to go against what is said here:
"At assembly-bind time, the components of the assembly display name
determine identity". (http://blogs.msdn.com/b/suzcook/archive/2003/07/21/57232.aspx)
Because if the identities are the same, why would .NET load it into the process a second time? It seems there are two different kinds of identities.
From that blog post what also doesnt make sense is this:
"Not all of the components matter in all cases. If the assembly is not
strongly-named, then the version is ignored for binding. But, if it is
strongly-named, the entire version in the assembly reference needs to
match the found assembly."
How does this make sense with what is said here:
"When this feature is enabled, strong names are not validated for
correctness when the assembly is loaded. The default is true"
(http://msdn.microsoft.com/en-us/library/cc679069(v=vs.90).aspx)
So strong names aren't validated at all which would make what Suzanne wrote in her blog post incorrect. Or what exactly is meant by "validation"? I think all of this boils down to a complete misunderstanding of assembly identity. I dont understand where and why and how an assembly identity matters in what ways.


Crash course in assembly identity: An assembly has a name and version, so far so straight forward. An assembly also has a culture; the implementations for different cultures may for example format date strings differently, and while they may have the same name and same version they do not do exactly the same thing. The public key token is part of a weak security measure to keep different publishers from producing assemblies with colliding identities.
Why would .NET load an assembly into the same App Domain multiple times?
Because the assembly is loaded in different load contexts. There is a context corresponding to default resolving behavior, a context to which copies loaded from a file path, and a context for other situations such as when the assembly is loaded from bytes in an assembly resolver. This behavior has been criticized since the types from assemblies with the same identity but in different contexts are treated as completely different types. See this MSDN article and this blog post:
https://msdn.microsoft.com/en-ie/magazine/dd727509%28en-us%29.aspx#id0400031
http://www.pabich.eu/2009/07/how-many-times-can-you-load-assembly.html
What does Suzanne Cook mean by validation? As a security mechanism (which has proven to be weak and easily broken) there is a private strong name key and a corresponding public key. The public key appears in the manifest of the DLL. The DLL is signed using the private key and the signature appears somewhere in the PE file - the PE header points to this information. A short form of the public key becomes the public key token. This ensures that only the publisher who holds the private key can produce binaries with a particular public key token, although this has security issues. This mechanism prevents assembly identity collisions between different publishers. Full trust assemblies have other signing mechanisms which ensure their authenticity. As an optimization, you can bypass checking the strong name signature since it is assumed fully trusted publishers won't attempt to collide assembly identities with each other. See more in this Microsoft doc:
https://learn.microsoft.com/en-us/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature
Bonus question: I want a strong security mechanism so that my customers can really trust my assemblies. I might even want to verify that components of my application are really published by me to prevent reverse engineering, licensing avoidance, etc. How do I do this?
SHA256 Authenticode signatures are the latest and greatest in signing any PE file, be it a managed assembly or an unmanaged binary. This is not a replacement for the public key token. The public key token is important for establishing assembly identity. The Authenticode signature is important for verifying assembly authenticity.
https://blogs.msdn.microsoft.com/ieinternals/2011/03/22/everything-you-need-to-know-about-authenticode-code-signing

Related

Does ReflectionOnlyLoad initialize or otherwise run any code?

For a project I'm working on I have to analyze several dozen assemblies.
It is very important that none of the code contained within these assemblies is actually being run, therefore I looked at Assembly.ReflectionOnlyLoad, as the documentation on MSDN mentions:
Loads an assembly into the reflection-only context, where it can be
examined but not executed. This member is overloaded. For complete
information about this member, including syntax, usage, and examples,
click a name in the overload list.
Now I know regular Assembly.Load runs either the initializers or the constructors of the objects it loads, but am I right in the assumption that this is not the case for ReflectionOnlyLoad, or should I be looking into other ways of achieving what I want?

ReflectionOnlyLoad will indeed forbid any code from the assembly from executing. It also has its own issues - notably, it's not cabaple of loading any dependencies. This can be tricky, since reflecting on a class deriving from a type defined in a different assembly will fail.
As far as I'm aware, Assembly.Load will not run anything in the assembly by default (EDIT: except for the module initializers, which could be abused; if you're not concerned with "hackers", this is not a problem, since normal C# code can't write module initializers, but it can be added in IL, and it might be present in C++/CLI assemblies), until you actually make it do so - for example, trying to get a value of a static field somewhere - but then again, doing that in a reflection only context will cause an exception.
In any case, whether you use ReflectionOnlyLoad or just plain old Load, make sure you're loading the assembly into a separate application domain. This lets you define different security contexts (no full trust for untrusted assemblies) and just as importantly, unload the assembly when you're done with it. If you don't load it in a separate application domain, you're not getting rid of the assembly until you restart your whole application.

How can a signed application use an unsigned assembly (which can be regenerated at customer sites)

My C# .net executable needs to be signed in order to use one of the methods in another of our assemblies that provides access to a password.
That same executable needs to reference and use an assembly that is not signed. The reason it is not signed is we provide a way for customers to regenerate it on site (it wraps access to modelled customizations in the app).
Is there any way the single executable can make use of both the signed and unsigned assemblies?

You can't reference unsigned assembly from signed assembly, but you can easily Load one using one of Assembly.Load methods.
Usually you provide interface (or base class if you like) in signed assembly and use that throughout code to obtain information at compile time. Customer's unsigned assembly (plugin) implements that interface on some specially marked class. Than your application loads the assembly (either from default location via Load, or from specified file via LoadFile), finds and constructs the class than uses it to obtain information at run-time.
Note: You may also look into "how to implement plugins in C#/.Net" questions for approaches.

I believe the only way for you to use an unsigned assembly is to load it at runtime using reflection.
You cannot a add strong name to your executable if it references something which is not strongly named.

How to prevent spoofing of DLLs in .NET

I have a .NET application that references a managed DLL.
This DLL contains a class, say ScoreKeeper that implements a method called GetHighScore(). The application calls this periodically.
Is there a way to prevent the .NET application from using a "non-authorized" DLL here in place of the one I am supplying?

You mention:
This DLL contains a class, say ScoreKeeper that implements a method called GetHighScore(). The application calls this periodically.
And then:
Is there a way to prevent the .NET application from using a "non-authorized" DLL here in place of the one I am supplying?
Assuming that you want to prevent someone from swapping out the assembly you have provided with an assembly of their own which has the same name and type (which is in the same namespace), you could apply a strong name to the assembly that contains the ScoreKeeper class and have your consumers reference that.
However, we'll see that there are issues that make this not 100% reliable. Strong Names help you protect unaware users from replacement of your DLL with a malicious spoofed copy. But if the user is complicit in the spoofing (which would be the case if he is trying to cheat), then code signing will be no more than a speed bump and provides no real protection. Certainly, Strong Names don't provide protection comparable to e.g. PunkBuster.
Using a Strong Name to verify an assembly publisher's identity
When you add a strong name to an assembly, you are using a private key (part of an asymmetric public/private key pair, more on this later) to generate a cryptographic hash and the public key is included in the assembly name (along with the hash).
Using the public hash and the public key, the CLR is able to verify that the signature of the assembly did in fact come from the private key.
Of course, this means, you should protect the key (internally and externally); if someone else has your key, then they can effectively impersonate you and publish assemblies that people would trust to be from you.
Then, when you add a reference to your signed assembly, if someone tries to put a different assembly in with the same assembly name (not the fully qualified one, just the name without version, hash and public key) and same type name, the CLR fill fail when trying to load the type, indicating that it couldn't find it; the type is resolved using the fully-qualified assembly name, along with the namespace and type name.
Why Strong Names are not 100% secure (is anything?)
1) Hash Collisions
It is still a hash that is being verified. While the hash is quite large (160 bits for the default hash algorithm, SHA-1), any hash that has a finite number of values is subject to a collision. While extremely unlikely, it is possible (impossible vs. improbable). Furthermore, only the last 8 bytes is used by default. Combined with research indicating that SHA-1 is relatively weak, this is a good reason to use SHA-256 Enhanced Strong Naming as described in MSDN.
2) Removal of the Strong Name
The strong name can be removed. However, in this case, because your assembly is referencing the strong named version of the referenced assembly, when your assembly tries to use the compromised version, it will fail at runtime, assuming you've correctly re-enabled verification (see below).
3) Physical access to the assemblies means all the assemblies
If someone has access to the physical machine and can modify the assembly that you are referencing, then your assembly is just as vulnerable. If the attacker has the ability to modify the strong name of an assembly that you referenced, then they can just as easily modify your assembly and all others involved in the execution. To this end, the only way to be 100% sure that the physical assembly isn't hacked is to deny physical access through it. Of course, that brings up a slew of different security concerns.
4) Administrator disabling the Strong Name check
The computer administrator can simply bypass the strong name check, using sn -Vr. According to MSDN:
Registers assembly for verification skipping... A malicious assembly could use the fully specified assembly name (assembly name, version, culture, and public key token) of the assembly added to the skip verification list to fake its identity. This would allow the malicious assembly to also skip verification.
5) Strong Name checking has to be explicitly enabled post .NET 3.5 SP 1
From .NET 3.5 SP 1 on, simply having a strong name doesn't provide any protection:
Starting with the .NET Framework version 3.5 Service Pack 1 (SP1), strong-name signatures are not validated when an assembly is loaded into a full-trust AppDomain object, such as the default AppDomain for the MyComputer zone.
In order to have .NET check the strong name of each assembly loaded into your application, you'll want to insert the following snippet (provided by MSDN) into your application configuration file:
<configuration>
<runtime>
<bypassTrustedAppStrongNames enabled="false" />
</runtime>
</configuration>
Beware, however, that this only protected against removal of the strong name.
When you override the bypass feature, the strong name is validated only for correctness; it is not checked for a StrongNameIdentityPermission. If you want to confirm a specific strong name, you have to perform that check separately.
If in light of the concerns above, you'd still like to pursue Strong Naming your assembly, here's how.
Generating a Strong Name and signing your assembly
You have two options for which key to use when generating a strong name. In Visual Studio, go to the Signing tab on the project properties and click "Sign the assembly":
From there, you have two options to generate the public/private key, to have VS.NET generate the keys for you, or point to an existing one:
When selecting "New", Visual Studio will prompt you for the name of the file to generate, as well as whether or not you want to optionally use a password to access it:
At which point, the key will be added to your project:
Now, you can move this to a solution item (if you have multiple projects in your solution).
Visual Studio in this case is really just calling the Strong Name command line tool to generate a public and private key pair. If you'd rather do that yourself, you'd want to call sn.exe with the -k command line option to generate the key, like so:
sn -k keyPair.snk
And then add it via the "Browse" dialog above.
Note that when you do this, it will pull the key into your project. If you don't want to do this (as it copies the key into every project), then delete the key from the project and then add an existing file to the project, but link it. This will clear the "Choose a strong name key file" option, but if you drop it down, you'll see the full path to your linked key file.

Seems like the most straightforward answer would be to calculate a secure hash of the DLL you are loading, and then compare it against a golden value that you have precalculated. Of course,this will still be vulnerable to being broken by a sufficiently determined attacker, but it will significantly raise the bar for people who want to cheat.

Changing public key token, how to redirect assemblies?

One of my customer wants to change the assembly signing policy.
Basically, all code and assemblies will be signed with the same and unique snk file.
Unfortunately, a very large code base is using the old public key token.
Is there a way to "redirect" old name to new name assembly?
I've read Assembly Binding Redirection, but it looks like it can only redirect to new version of the same assembly name/public key token.
While I can recompile code, I have a lot of aspx and ascx referencing the old name. I also have 3rd party database that serialize some objects in binary format. I can't change that easily.

How hard is it to tamper with a strong named assembly?

Assume I have a .NET assembly which is strong named. Only I have access to the private key. I then distribute the assembly to some client system.
How hard is it for the client to modify the assembly? Ie: what would they need to do to modify my assembly?

Strong-naming does not prevent modifying the assembly, but it does prevent other applications which reference a strong-named assembly from inadvertently using a modified version.

It's no different from modifying a non-strongly typed assembly. The only real difference is that they would have to run the strong name utility (sn.exe) in order to use the modified assembly.

As others have said, its very easy.
One technique you can use is to use the public key (or token) of your assembly to encrypt important information (such as algorithm parameters, connection strings, etc) in your assembly. This way if the public key has been changed or removed, the decryption will fail and your assembly would no longer run correctly. Obfuscators such as Crypto Obfuscator use this technique as one part of the protection.

Categories