Are signed .net assemblies ever fully verified when loaded, to check they haven't been modified?

Question

I used to think that .net assemblies that were signed and/or strong-named were verified by the CLR when loaded, meaning that it wasn't possible for someone to edit the IL and still have a valid assembly. Then I listened to this great Herding Code podcast where Jon McCoy said that doesn't really happen (approx 12:47 in the podcast) - i.e. anyone can edit the IL and mess with your assembly and the CLR will not care. I know this sounds weird, but he seems to know what he's talking about, so perhaps it's just that I don't know exactly what scenarios he's referring to.

Can someone explain if & when the CLR will actually verify the full contents of an assembly to ensure that someone hasn't tampered with the IL? If 'signing' or 'strong naming' doesn't do it, what process do you need to make the CLR check an assembly properly?

Some other references (that haven't made it entirely clear to me - probably I'm just a bit slow):

Talks about editing the IL and bypassing the strong name signing Validating .NET Framework Assemblies (I don't know if this is the same sort of attack referred to by Jon).
Says attacker can resign with his own key but can't leave your signature intact : Can strong naming an assembly be used to verify the assembly author? (i.e. not the same attack referred to by Jon)
Saying from .net 3.5 CLR doesn't verify assemblies under full trust: Why does .NET not verify the BCL/CLR? (maybe this is what Jon means?)
How to verify an assembly: How to programmatically verify an assembly is signed with a specific Certificate?
Grey Wolf (by Jon McCoy) - for copying strong name signing on assemblies !? https://www.digitalbodyguard.com/graywolf.html

.NET 3.5SP1 put an end to the illusion that strong name verification is useful if you keep assemblies in the same place. Which is pointless, an attacker can of course replace *more* than one assembly. You can turn it back on if you really want to, use the `` config element. — Hans Passant, Nov 20 '13 at 21:29
@HansPassant, could you explain why strong name verification is pointless if assemblies are kept in the same place? — sean717, Dec 02 '13 at 18:25
@sean717 because if you can edit one assembly, you can edit the other and change the expected signatures — porges, Oct 20 '16 at 02:23

user3517618 · Accepted Answer · 2014-04-10T01:48:58.103

This is Jon McCoy :) Yes the strong name signing can be bypassed. WHY/HOW-> The Runtime only checks the strong name signing key/cert but does not Hash the DLL/EXE to match the key. If the OS(Windows) has the .NET Framework set to turn Strong name Sign checking on then it will but this is off by default.

FIX Ideas: Link to turn the bypass off: http://msdn.microsoft.com/en-us/library/cc713694%28v=vs.110%29.aspx

Also some protection systems will have a known hash to check but this can be removed.

You could enforce it as an IT policy and in windows.

Yes: My Tool GrayWolf(free on http://www.DigitalBodyGuard.com) changes the IL and moves the Keys from the old one to the new changed copy, the keys would not match the HASH of the DLL/EXE they are on but no one checks:)

P.S. it would slow the boot time to check the Hash

Are signed .net assemblies ever fully verified when loaded, to check they haven't been modified?

1 Answers1

Linked