Faster than light neutrinos
-
I am a in disbelief. I was experimenting with strongly signed libraries lately and found a couple of surprising things. Scenario 1: I create a program and sign it using a strong name key file:
public main()
{
Console.WriteLine(0x42);
}My first surprise was that if I edit the executable file with a binary editor I can make it display any other number. It appears that the signatures are not checked at run-time. I then pushed it a bit further. I can push the original assembly to the GAC but not the modified version. As it returns :
"Failure adding assembly to the cache: Strong name signature could not be verified."
This is expected and I felt a bit better about it. Scenario 2: ...Until I tried to copy the modified assembly directly into the assembly cache folders. If I overwrite the assembly in :c:\windows\assembly\gac_64\MyAssemby\2.0.0.0__ba22423234234234a
(you might have to check that the library is not already ngen'd) Then the tempered library will be used successfully by any program despite the fact that the signature is wrong... In other word someone could make an alternative version of System.dll or System.Web and any .Net program on the machine will obliviously run it. ... I'd love to have missed something. Please tell me I am wrong.
-
I am a in disbelief. I was experimenting with strongly signed libraries lately and found a couple of surprising things. Scenario 1: I create a program and sign it using a strong name key file:
public main()
{
Console.WriteLine(0x42);
}My first surprise was that if I edit the executable file with a binary editor I can make it display any other number. It appears that the signatures are not checked at run-time. I then pushed it a bit further. I can push the original assembly to the GAC but not the modified version. As it returns :
"Failure adding assembly to the cache: Strong name signature could not be verified."
This is expected and I felt a bit better about it. Scenario 2: ...Until I tried to copy the modified assembly directly into the assembly cache folders. If I overwrite the assembly in :c:\windows\assembly\gac_64\MyAssemby\2.0.0.0__ba22423234234234a
(you might have to check that the library is not already ngen'd) Then the tempered library will be used successfully by any program despite the fact that the signature is wrong... In other word someone could make an alternative version of System.dll or System.Web and any .Net program on the machine will obliviously run it. ... I'd love to have missed something. Please tell me I am wrong.
If you look at older publications such as this http://msdn.microsoft.com/en-us/magazine/cc163583.aspx[^] from 2006 you would come to the conclusion that strong naming signing an assembly would give some measure of tamper proofing. So it does come as a bit of a suprise to find that you can fire up a binary editor, change some data and it will still load. It turns out that load time checks for applications operating in a Full Trust environment were disabled by default when .NET3.5 SP1 was released, a change that affected the behaviour of .NET2.0 as well. This Strong-Name Bypass feature can be enabled or disabled on a system wide basis via a registry setting or a per application basis with an entry in the app.config file. It's explained in MSDN .NET4 docs[^] although I only found out about this after I had discovered that an edited strong named signed assembly would load without complaint. One would hope that the Authenticode signature mentioned in that reference is protecting the core system assemblies. Alan.