3

I searched for proctecting .net assemblies from spoofing and found this post very useful. However, I see a very clear contradiction in the post. In one point it is stated that strong name is not useful if the user is complicit:

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.

And few lines later the writer states something completely in contrast:

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.

So:

1) Is this a contradiction or I am loosing something? Is the writer in the first paragraph talking about the situation in which validating strong name was disabled and is not going to be re-enabled?

Moreover,surprisingly it is stated that:

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

2) How is it possible to modify a deployed assembly's (for example a DLL) strong name?

Community
  • 1
  • 1
Alireza
  • 10,237
  • 6
  • 43
  • 59
  • 1
    Did you read the section "4) Administrator disabling the Strong Name check" ? This overrides the bits in your `app.config` that enable the check. – Ben Voigt Jun 30 '14 at 23:02

1 Answers1

1

There doesn't appear to be a contradiction here - the second quote indicates correctly that simply replacing the referenced assembly with another one containing types of the same name, has a different (or no) strong-name will fail because this assembly will not match the one indicated in the reference. Essentially, this is the system's way of protecting itself from modification not intended by the user.

However, if the modification is intended (i.e. the user is complicit, per the first quote) then there are simple means to enable loading of a modified assembly, for example by disabling strong-name checks (which would allow an assembly with an invalid signature, say as a result of it having been modified) to still be loaded, or by changing the assembly reference itself.

In answer to your second question, whilst the standard assembly signing tool sn doesn't have an option to replace an assembly's strong name with another, it is certainly possible, and a brief search should find various tools capable of doing so. (In fact, it's easy enough to do it with a simple hex editor).

Iridium
  • 23,323
  • 6
  • 52
  • 74
  • This is a correct answer. It could be extended with some stuff about how to perform assembly redirection in the app.config, which is an easy way for the user to inject a replacement strong assembly. – Casper Leon Nielsen Jan 04 '13 at 16:49
  • I am still confused. If validating strong name is disabled, it can be always re-enabled by adding a proper code sinppet in app.config. Is there any other way to bypass a faked assembly? Moreover, if it is so easy to copy the strong name of an origional assembly to a faked one, then it is very unlikely to trust even my own personality! – Alireza Jan 04 '13 at 17:37
  • @Alireza you can't simply copy the strong name of one assembly to another, so providing strong name verification is enabled, you can be sure that if you're referencing your own strong-named assembly, that it is legitimate. However you can delete a strong name from an assembly, or replace the signature with one created by a different key, but both of these change the identity of the assembly such that a reference to the original strong-named assembly will no longer function. – Iridium Jan 04 '13 at 19:04
  • @CasperLeonNielsen As far as I know, assembly redirection only allows you to redirect to a different version (``) or a different location (``), however in both cases, the assembly identity must match the reference, so unless you can create another assembly with the same strong-name (which would essentially require the signer's key), this isn't a means to arbitrarily redirect a reference to an alternative assembly (assuming strong name validation is enabled). – Iridium Jan 04 '13 at 19:25
  • Ok, thank you for clearing that up. My memory just told me you could redirect to another version. Did not realize that it still needed to be the same signer. – Casper Leon Nielsen Jan 07 '13 at 07:47