Sendhil's Cyber Home

Dll Hell

Suppose I author a security.dll and some other company companyX also authors another security.dll. If both of us have multiple applications using this security.dll and decide to deploy it into a well-known location in the path say, the system folder. Suppose the end user installs Applications A & B using security.dll and this is installed into the system folder. End user also happens to install Applications C & D which deploy companyX’s security.dll overwriting my security.dll. What happens when the end user runs Application A or Application B. It’s a disaster in waiting.

Another scenario is deploying multiple versions of the same library (side-by-side execution). Suppose Application A needs version 1.0 of security.dll and Application B needs version 1.1 of security.dll how do we deploy incompatible versions 1.0 and 1.1?

This is called dll hell.

To avoid dll hell, we can deploy applications such that each application has its own copy of the referenced libraries. Assume if multiple applications reference the same library then multiple copies of the library exist in the machine. Updating this is a pain and disk space usage is also high.

So libraries used by multiple applications must be deployed on a shared location. Relying on file name to be unique is not good. How do we deploy different versions of assemblies into a well-known location? How do we deploy libraries from different vendors into a well-known location?

GAC, Strong Name

Welcome to the Global Assembly Cache and strong name. Global assembly cache is a file store, which keeps the libraries inside sub-directories based on library name, version, culture and publisher. When we say publisher, how do we uniquely identify a publisher? COM used GUIDs to uniquely identify things. CLR uses the public key / public key token of a cryptographic key pair to uniquely identify a publisher. This key pair (because of signing using this key pair) also helps the CLR to keep the assemblies tamper-proof.

Fully Qualified Assembly Name

An assembly name (fully qualified assembly name) has four parts to it

• File name (without extension) of the file containing the assembly manifest
• Version
• Culture
• Public key token

What is this Public key token?

Since fully qualified names are used in the assembly reference metadata tables using the whole public key will bloat the size of these tables and the assembly. A public key token is a 8 byte hash of the public key.

GAC Folder Structure

When I deploy version 1.0.0.1 of companyX.Infrastructure.Security.dll with public key token 8b95326fea73ef1783b073 for culture en-US in GAC. The folder it is deployed in file system as follows (for the current CLR version):

Under the <Root GAC folder>

companyX.Infrastructure.Security1.0.0.1_en-US_8b95326fea73ef1783b073

This allows you to deploy multiple versions of the same assembly into GAC. This also allows libraries of same name from different publishers to be deployed into GAC. Since the public key token for different publishers is different the folders will be different in GAC.

How do you prepare an assembly for deployment in the GAC?

• Generate a public private key pair using sn.exe.
• Give the key file path in AssemblyKeyFileAttribute ( in assemblyinfo.cs /.vb if you use VS.NET)
• When the project is built, the compiler signs the assembly (we will see this in detail later).
• Use GACUtil.exe to deploy the assembly into the GAC.

(Actually a drag drop into GAC folder using Windows Explorer should do, the shell extension fusion.dll does the magic of installing the assembly into GAC)

The signing process

When the compiler builds the assembly

• it generates a hash of the each file in the assembly and stores it in the FileDef metadata table.
• it reads the key pair from the key file.
• it embeds the publisher’s public key into the manifest.
• Once the file containing the manifest is built, it hashes the entire contents of the file and signs the hash using the publisher’s private key.
• it then stores the RSA digital signature of the hash into a reserved section in the CLR header (Not included in the Hash)

During the installation into GAC CLR does the following:

• it reads the RSA digital signature of the assembly from the CLR header.
• it reads the publisher’s public key from the manifest.
• it gets the hash value from the digital signature using the publisher’s public key.
• it then hashes the contents of the file containing the manifest and compares it with the original hash obtained from the RSA digital signature.
• If they match the file containing the manifest has not been modified.
• It then hashes the contents of the other files that comprise the assembly and compares it with the hash values read from the manifest filedef metadata table.
• If these hashes also match the assembly has not been tampered.

During load time CLR does the following (for strongly named assemblies):

• If it is loaded from the GAC no tamper verification happens.
• If it is loaded from the bin directory then, the CLR does the verification as mentioned above.

Delay signing

Bigger corporations cannot risk distributing the private key to all their developers. Instead they use delay signing. AssemblyDelaySignAttribute asks the compiler to just reserve a space for the digital signature in the CLR header. The developer then uses sn to suppress verification for this assembly. Once the development cycle is complete sn can be used to sign the assembly again with the private key. This will be done by a trusted source after all the development is completed.

Other Trivia

The gacutil is installed with the Framework SDK, .NET Runtime installation doesn’t install gacutil. So end-user deployments must install into the GAC using Windows Installer 2.0 or above.  GACUTIL allows to track applications which reference a library

/ir
Installs an assembly to the global assembly cache with traced reference. Include the name of file  containing manifest, reference scheme, ID and description as parameters. Example: /ir myDll.dll FILEPATH c:appsmyapp.exe MyApp.

The same can be done using installer too.

References:

"CLR Via C#" by Jeffrey Richter

"Essential .NET, Volume 1 – The Common Language Runtime" by Don Box.