Hacker News Reader

Comment by rubyrescue | Hacker News Reader

My knowledge of the GAC is out of date but isn't a bit of a security hole that you can replace that DLL?

They didn't replace it - it looks like they created a new assembly with its own strong name, registered it alongside the 'official' assembly, and referenced their assembly in place of the .NET native assembly at compile time.

What's maybe surprising is that the C# compiler generated code 'adopts' the types in their hacked expressions library. But the C# compiler, wherever it depends on particular types that need to exist for it to do its thing, has always generally relied on finding those types by -name-, not by -name and assembly strong name-.

For example, the C# 3 compiler understands the calling and declaration syntax of extension methods, but to compile an extension method, it requires an Attribute type - System.Runtime.CompilerServices.ExtensionAttribute - which was only introduced into .NET in v3.5. But if you make an attribute class with that name available to the C# compiler, you can compile code using C#3 extension method syntax against the .NET 2.0 framework libraries.

You need to be a local administrator to write to the GAC by default. See http://msdn.microsoft.com/en-us/library/yf1d93sz(v=vs.110).a...

So if you can modify the files in the GAC, you're already compromised at that point.

Writing to the GAC is easy, but assemblies in the GAC are strongly-named. Actually replacing one without the private key would require forging a signature, which is what parent was probably referring to. You can give an assembly the same name, but if it's signed with a different key it gets a different strong name (and therefore goes in a slightly different directory).

I don't think it's a replacement, since signing the new DLL would require a new key. (GAC DLL identity basically comes down to name + signing key. So even if you call it System.Whatever, it has a unique identity)

Reply on news.ycombinator.com