.NET Security Blog : Under the Hood

CAS and Native Code

shawnfa — Tue, 04 Mar 2008 21:27:41 GMT

CAS is complicated enough to understand when all of the moving parts are written in managed code (and therefore have all the associated managed meta-information like grant sets, etc). However, once native code comes into play things can get even more confusing. Let's take a look at how CAS works when there's native code on the call stack.

For this discussion, lets assume we have a call stack (growing down) like so:

Managed code: M1

Managed code: M2

Native code: N1

Managed code: M3

Managed code: M4

AppDomain: AD

So in this example, M1 calls M2, which calls N1, which calls back to managed code M3 and M4. All of the managed objects live in AppDomain AD.

Full Demands

Now lets consider what happens when M4 triggers a full stack walk for a demand. In this case, the CLR essentially ignores the native code on the stack, and does a stack walk looking at M3, M2, M1, and AD. Intuitively, this is done because the native code doesn't have a grant set associated with it, and therefore including it on a CAS stack walk wouldn't make much sense.

It's important to note however that the stack walk proceeds through N1, rather than stopping at it. So in this case if M3 and M2 are fully trusted, but M1 is partial trust and M4 triggered a FullTrust demand, that demand would fail.

Stack walk modifiers like Assert continue to work just as you would expect as well, so it's perfectly legal for M2 to Assert FullTrust, which would make M4's demand succeed.

Link Demands

Link demands are much more interesting when native code gets involved. In our example, imagine that managed method M3 has a LinkDemand for FullTrust on it. Normally, LinkDemands are evaluated at JIT time against the caller of the method with the demand. But in this case, the caller of M3 is native code which is not JITed (and doesn't have a grant set to evaluate against in any event).

The obvious solution then is to evaluate the LinkDemand against the last managed frame on the call stack before we transitioned to native code. At the time we're JITing this method however, we only know that it's calling a native method -- we don't know what managed code that native code is going to turn around and call later on. In this example, when M2 is being JITed we know that it may call N1, however we don't know that N1 will turn around and call M3 and therefore don't know that M3 has as a LinkDemand to evaluate against M2.

However, it turns out that we don't need to know what M3 is going to LinkDemand of M2. Since M2 is calling N1, it must have UnmanagedCode permission, and since UnmanagedCode permission is never handed out without FullTrust, we can reason that M2 must be fully trusted. If M2 is fully trusted, then it will satisfy any LinkDemand that M3 will require.

With this analysis, we could say that LinkDemands are implicitly satisfied by native code callers. However, that may not be the effect that we want in all cases. For instance, one common scenario might be to expose a managed object via COM Interop to a script. (For instance, make a managed object available via COM to some JavaScript in a web page).

From the CLR's perspective, this script is just native code, so our reasoning would lead to any link demands on methods the script calls being satisfied. However, we may not want the script to satisfy all link demands. In order to solve this problem, the CLR treats calls to managed code from native via COM Interop differently.

If native code uses a COM interface to call a managed method protected with a LinkDemand, then that LinkDemand is evaluated against the AppDomain which the managed object lives in.

Let's go back to our example again, and see how these rules apply. Let's suppose that N1 calls M3 through COM Interop, M3 has a LinkDemand for FullTrust, and the AppDomain AD is also fully trusted. In this case, the call succeeds because the AppDomain's grant set satisfies M3's LinkDemand.

Now let's consider the case where this AppDomain is hosted by Internet Explorer, and therefore has only the Internet grant set. When N1 calls into M3, we'll see that the object M3 is being called on lives in AppDomain AD, and that causes us to look up the grant set of that domain. We then check M3's LinkDemand for FullTrust against the AppDomain's grant set of Internet. Since the AppDomain's grant set does not satisfy the LinkDemand, we throw a SecurityException. Note that this is true even if the last managed frame on the stack (M2) is fully trusted.

If we make one more change to the scenario, and have N1 call M3 via reverse P/Invoke we a different result. Even though the AppDomain is partially trusted, since M3 was not invoked from COM Interop, we allow the call to succeed.

3 Rules for Native Code CAS Evaluation

That's a ton of complexity, but thankfully we can boil it down to three rules depending upon your scenario:

If a full demand is done, native stack frames are ignored and the stack walk proceeds exactly as if there were only managed frames on the stack.
If a link demand is done via COM Interop, the link demand is evaluated against the grant set of the AppDomain that the managed object lives in.
If a link demand is done via reverse P/Invoke, the link demand is satisfied and the call succeeds.

Combining Strong Names with Authenticode

shawnfa — Wed, 10 Jan 2007 21:32:39 GMT

If you want to use both a strong name and Authenticode signature on your assembly (for instance if you need a strong name for strong assembly identity, and your company has a rule requiring Authenticode signatures on all shipped products), then you need to make sure to do these in a specific order.

Strong name the assembly
Authenticode sign the assembly

The reason for this is that since Authenticode signatures were invented before strong naming was a twinkle in someone's eye, they don't know anything about strong name signatures. However, the CLR does know about both signature types, and can therefore make sure that signatures are applied in a manner that allows both to validate.

Why does the CLR have to do anything at all to allow both signatures to validate? Imagine for a minute that no extra work is done in the dual-signature case, and that we just hash and sign the assembly. When you strong name sign the hash is of the assembly with no signatures; however the Authenticode signature will be with the hash of the assembly containing the strong name signature. During verification, the problem appears -- when verifying the strong name signature the hash of the assembly is different than the one calculated during signing, because the Authenticode signature is now part of the assembly. If we attempt to fix this by resigning the assembly after Authenticode signature is applied the reverse is now true -- the hash of the assembly with the original strong name signature (which is what the Authenticode signature contains) is now different from the hash with the new strong name signature.

In order to prevent this cycle, when the hash of an assembly is calculated the CLR actually zeros out the directory entry in the optional headers of the PE file for the Authenticode signature, and will skip over the section of the file containing the Authenticode signature itself. This means that the hash used for the strong name signature does not include any Authenticode information at all. Since you should always strong name sign first, this step actually does nothing during the signing stage because there will not be an Authenticode signature to skip. However, during the verification process there will be an Authenticode signature present . By zeroing out the directory entry and skipping the section of the PE image containing the Authenticode signature the hash will be the same as it was at signing time -- therefore allowing the strong name signature to verify.

Since Authenticode doesn't know anything about strong names, it does not treat the strong name signature in any sort of special way. That's why it needs to be applied after the assembly is strong name signed, since it needs to see the exact same bits during signing and verification. Note that this means that if you're delay or test key signing, you need to apply the Authenticode signature after the final signature is calculated, not just after the assembly is built.

Incidentally, the Authenticode signature is not the only section of the PE file that is not covered by the strong name signature. We also skip the checksum field of the PE header and the strong name signature blob.

Special Permissions in the SSCLI

shawnfa — Tue, 06 Jun 2006 19:00:00 GMT

Before digging into a pretty clever optimization that the SSCLI makes for certain special permission demands, I want to point out that everything I’m about to cover is an implementation detail. Although this optimization does occur today, we can and will change it for future versions of the CLR (and potentially service packs for the v2.0 version) … the only thing guaranteed about the behavior of a demand is that it throws a SecurityException if the call stack does not meet the required permissions; and does nothing if it does.

With that being said, the v2.0 CLR has a few special permissions which it can apply a clever optimization to in order to speed up demands. If you’ve got the SSCLI v2 installed, you can see these permission defined in managed code in the PermissionType enumeration (clr\src\bcl\System\Security\CodeAccessSecurityEngine.cs) and mirrored in the VM (clr\src\VM\SecurityPolicy.h). (Look for the set of #defines starting at line 297 with SECURITY_UNMANAGED_CODE).

There are two categories of these special permissions defined:

A flag of a permission (Assert, SkipVerification, UnmanagedCode, etc)
An unrestricted permission (UI, Environment, Security, etc)

Each of these is given an integer value in SecurityPolicy.h which matches its value in the PermissionType enumeration. The CLR maps these values into flags by using the corresponding bit of a DWORD to indicate that this permission is the one being talked about. For instance, given:

#define UI_PERMISSION 9

We use 1 << UI_PERMISSION or 0x00000200 as a flag to indicate that we’re referencing unrestricted UI permission. In this way, we can simply logically or together as many of these permissions as is needed to talk about any given set of the special permissions. This does imply a limit of 32 special permissions however -- currently the CLR defines only 18, so there is plenty of room to grow there. One interesting thing to note is that although we do define SECURITY_FULL_TRUST to be bit 7, generally the VM uses 0xFFFFFFFF to refer to the FullTrust special permission bitmask.

Calculating Special Permission Flags

When an assembly or an AppDomain is loaded, policy is resolved to get the grant set. The entry point for this resolution is SecurityPolicy::ResolvePolicy (clr\src\VM\SecurityPolicy.cpp), which takes the parameters you would expect such as the evidence and assembly level declarative permission sets. It returns the grant set, and as an out parameter the denied permission set. As an extra out parameter, dwSpecialFlags, is the set of special permission flags which are calculated from the grant and deny set.

The logic is to return a bitmask that represents everything that was in the grant set and not in the deny set. So if an assembly was being resolved in SecurityPolicy::ResolvePolicy, and its grant set included SkipVerification, UnmanagedCode and unrestricted UIPermission while its deny set included SkipVerification and unrestricted EnvironmentPermission, the output would be:

((1 << SECURITY_SKIP_VER) | (1 << SECURITY_UNMANAGED_CODE) | (1 << UI_PERMISSION) ) &
    ~( (1 << SECURITY_SKIP_VER) | (1 << ENVIRONMENT_PERMISSION) ) = 
(0x00000103) & !(0x00000402) = 
0x00000103 & 0xFFFFFBFD = 
0x00000101 = 
(1 << UI_PERMISSION) | (1 << SECURITY_UNMANAGED_CODE) 

Which is what we would expect when you take the set (SkipVerification, UnmanagedCode, UIPermission) and remove (SkipVerification, EnvironmentPermission).

The actual work of resolving policy and calculating these flags is delegated by SecurityPolicy::ResolvePolicy to System.Security.SecurityManager.ResolvePolicy (clr\src\bcl\System\Security\SecurityManager.cs). After ResolvePolicy computes the grant and deny sets, it passes those to SecurityManager.GetSpecialFlags, whose job it is to do the mapping from the permission sets to any appropriate special permission flags. It does this by scanning for any flags on permissions which have their flags represented in the special permissions (currently just SecurityPermission and ReflectionPermission) and saving those flags away. It also does a scan for any permissions which have their unrestricted permissions set as a special flag, saving those as well.

Once all the permissions which may map to a special flag are found, SecurityManager.MapToSpecialFlags is called to map the flags from SecurityPermission and ReflectionPermission back to an appropriate flag, while the GetSpecialFlags method itself adds bits for any of the other permissions which are unrestricted.

I mentioned earlier that FullTrust is represented as 0xFFFFFFFF rather than 0x00000080, you can see that mapping in the very first line of SecurityManager.GetSpecialFlags.

Security Descriptors and Special Permissions

The base SecurityDescriptor class (clr\src\VM\SecurityDescriptor.h) defines a protected member, the DWORD m_dwSpecialFlags, which holds the set of special permission flags that apply to the VM object the security descriptor refers to (such as an AppDomain or Assembly). In addition to this set of flags, the ApplicationSecurityDescriptor (clr\src\VM\SecurityDescriptorAppDomain.h) defines a second member to hold these flags -- m_dwDomainWideSpecialFlags.

The m_dwSpecialFlags member is populated with the result from calling SecurityPolicy::ResolvePolicy on the object being loaded. The extra field in the ApplicationSecurityDescriptor however is kept up to date differently, and allows us to perform an optimization when a demand for one of these special permissions comes in.

After the AppDomain has had its policy resolved, m_dwDomainWideSpecialFlags is initialized to match the special flags of the AppDomain. (This is done in ApplicationSecurityDescriptor::InitializePLS in clr\src\VM\SecurityDescriptorAppDomain.cpp). This means an AppDomain with no loaded assemblies has an m_dwDomainWideSpecialFlags indicating the special permission grant set of the domain itself.

As each assembly is loaded into the AppDomain, the AssemblySecurityDescriptor’s m_dwSpecialFlags is initialized while policy is resolved on that assembly. (See AssemblySecurityDescriptor::ResolveWorker in clr\src\VM\SecurityDescriptorAssembly.cpp). The AppDomain then updates the m_dwDomainWideSpecialFlags field with the information from the AssemblySecurityDescriptor in ApplicationSecurityDescriptor::AddNewSecDescToPLS. The domain wide flags are updated by doing a bitwise and between the current domain wide flags and the flags of the assembly’s security descriptor.

Following this logic along, the domain wide special flags start out as the set of special permissions granted to the AppDomain itself, and then are potentially reduced by each assembly loaded so that at any given point the domain wide special flags are always the set of special permissions which are granted to every assembly in the domain as well as the domain boundary.

With that setup, if a demand for one of the special permissions is done in the AppDomain, we can check to see if the domain wide flag for that permission is set. If it is, then the CLR can cause the demand to succeed without ever having to do a stack walk, since it knows that for the special permission bit to be set everything in the AppDomain must be granted the given permission. The code which maps the permissions in a demand to a set of special flags is in SecurityStackWalk::GetPermissionSpecialFlags (clr\src\VM\SecurityStackWalk.cpp).

Obviously this optimization does not work in the face of stack walk modifiers such as Deny or PermitOnly, which can cause the permission set of the call stack to become a subset of the permissions granted to the assemblies in the domain -- and if you look at the code in SecurityStackWalk::HasFlagsOrFullyTrustedIgnoreMode (clr\src\VM\security.inl) this is what the check for pThread->GetOverridesCount() == 0 is doing. [But as Alton Brown might say, that’s another show.] This is just one more reason that you really want to avoid using Deny and PermitOnly in your code if at all possible.

Also note that this logic works for determining if a demand will pass, however it cannot be used to determine that a demand will fail. For instance, if an AppDomain has assemblies A, B, and C loaded into it, and the AppDomain, assembly A, and assembly B are all granted SkipVerification while assembly C is not, the SECURITY_SKIP_VER bit will be clear on the domain wide flags. However, if a skip verification demand is done while only A and B are on the call stack (or if C is on the stack, but either A or B has done an Assert preventing a stack walk from reaching C), then the demand will still succeed even though the bit is clear.

The take away from this is not that you should try to only demand special permissions -- again, these were all implementation details subject to change at any point. You should always demand the most appropriate permission for the resource you’re trying to protect. More importantly, it’s interesting to see how the CLR can optimize the performance of some demands, and how operations like Deny and PermitOnly can ruin the optimizations.

How does the CLR figure out Zone evidence?

shawnfa — Fri, 12 May 2006 23:14:00 GMT

This week, I've had three separate cases where people have wondered why the CLR was assigning seemingly incorrect zone evidence to their assembly, causing their permission sets to be less than what was expected.

The quick and dirty answer is that the CLR doesn't in fact assign zones (with one small exception). What we do is ask Windows for zone information.

If we can look at the URL of the assembly and tell that it's from the local machine, then we'll take a short cut and assign it MyComputer zone evidence directly. However, if it's not obvious to us that the URL does belong to the local machine, we'll call urlmon via IInternetSecurityManager::MapUrlToZone in order to assign a zone.

It's relatively easy to slap together a quick function that checks what zone urlmon is assigning a URL with this API:

HRESULT MapUrlToZone(const std::wstring &wsZone, DWORD *pdwZone)
{
    if (pdwZone == NULL)
        return E_POINTER;

    IInternetSecurityManagerPtr pSecurityManager;
    HRESULT hr = CoInternetCreateSecurityManager(NULL, &pSecurityManager, 0);
    if (FAILED(hr))
        return hr;

    hr = pSecurityManager->MapUrlToZone(wsZone.c_str(), pdwZone, 0);
    if (FAILED(hr))
        return hr;

    return S_OK;
}

The DWORD can be translated to a name with the GetZoneAttributes API, checking the szDisplayName field in the ZONEATTRIBUTES structure that you're returned. For quick reference however, MyComputer is 0, LocalIntranet 1, TrustedSites 2 and Internet 3.

What Happens When You Fully Sign a Test Signed Assembly

shawnfa — Tue, 04 Apr 2006 00:44:00 GMT

When an assembly is test signed, the public key used to verify its signature is different from the public key that makes up part of the assembly identity. So what happens when you take an assembly which is registered as a test signed assembly on your machine and fully sign it?

The key here (aren't puns fun) is the fully signed bit in the CLR header. An assembly which is fully signed (so not simply named, test signed, or delay signed) has the COMIMAGE_FLAGS_STRONGNAMESIGNED bit set in the Flags field of the IMAGE_COR20_HEADER. (Both can be found in corhdr.h in the Framework SDK)

If the CLR is verifying a signature, and it sees this bit set, it won't even attempt to check the skip verification or test sign lists. Instead, verification proceeds with the public key embedded in the assembly itself. So the answer to the question is that a fully signed assembly with a entry on the test signed assembly list will work as expected, and verify with the correct public key.

In the SSCLI v2, you can see this behavior in the strong name code located at sscli20\clr\src\VM\strongname.cpp. Specifically, go to the VerifySignature method -- the relevant code starts at line 2498. On 2504 we check to see if the fully signed bit is in place, and if not we check for a test public key on 2506. The magic behind test key signing is essentially on one line of code, line 2514, where we substitute the test public key for the assembly's real public key.

LinkDemands and InheritenceDemands Occur at JIT Time

shawnfa — Wed, 11 Jan 2006 22:55:00 GMT

We previously saw that the SkipVerification demand for calling a method with unverifiable code occurs at JIT time rather than at runtime. Two other types of demands also occur at JIT time, LinkDemands and InheritenceDemands. An InheritenceDemand will occur when the method of the derived class is being JITed, while a LinkDemand occurs when the method which calls the method containing the LinkDemand is being JITed. For instance, if method A calls method B, which has a LinkDemand for FullTrust, the demand occurs when A is JITed. If method C overrides a method in class D which is protected with an InheritenceDemand, the demand occurs when C is JITed.

This has some interesting consequences. Since the basic unit of JIT compilation is the method, you cannot have a single method which checks the permission set its running with, and then conditionally calls a method protected by a LinkDemand if if would satisfy that demand. Instead, it would have to check it's permissions and if it had enough call another method which simply turned around and called the method with the LinkDemand. Similarly, you cannot do a try ... catch(SecurityException) around a method protected by a LinkDemand.

I recently was asked a question about a program that stopped working when it was moved to a file share. The author of the application attempted handle this gracefully by displaying an error message to his users indicating that they need to increase the trust of the application. However, even that code didn't help -- it seemed as though the application's Main method never even got to execute.

It turns out that Main created a Mutex object, and the Mutex constructor contains a LinkDemand for UnmanagedCode. Now that we know that this demand will occur at JIT time, the observed behavior seems understandable. When the JIT attempted to compile Main, it found a call to a method that had a LinkDemand for UnmanagedCode, and so checked the permission set of the assembly containing Main. It then found that this assembly did not have UnmanagedCode Permission, so it threw a SecurityException rather than compiling the method. This prevented the author's attempt to fail gracefully from ever running, and the application died with an unhandled exception. In fact, since this occurred while JITing Main, there actually wasn't even a call stack yet, so the exception message wasn't even particularly helpful in tracking down the problem.

One way to fix this is to have Main first do the check for FullTrust, then call another method which does the work that used to occur in the original Main method. This way, the application's entry point is allowed to JIT, and it can provide a useful diagnostic message to the users in the case that they need to provide extra trust for the code.

Exploring the ADMHost Sample

shawnfa — Fri, 07 Oct 2005 01:10:00 GMT

When I first talked about AppDomainManagers, I mentioned that there were three ways to set them up. You can either setup an environment block, use some registry keys, or use the unmanaged hosting API. In most of my samples so far I've used the environment variables, and in fact I discourage using the registry keys.

That leaves the unmanaged hosting API as the only entry point for setting up an AppDomainManager that I have left to explore. Since this involves a decent chunk of code, I've posted it as a downloadable MSDN sample, ADMHost rather than putting it in the blog directly.

ADMHost exists as a basic template of an application that uses managed and unmanaged hosting -- by itself it's not very useful, in fact it just prints Hello World and exits. However, it does demonstrate how to split your host into a managed and an unmanaged half using AppDomainManagers, and you can replace the "Hello World" logic with your own application specific logic in just a couple of minutes.

A Whirlwind Tour of a CLR Host

Let's take a look at the code then. It comes as a solution that will open in Visual Studio 2005 beta 2 or later, and a set of pre-built binaries. (By default the output will not work on Win9x, however the project could be pretty easily tweaked to support those platforms if you need). The solution consists of two projects, ADMHost which is the unmanaged entry point and the unmanaged half of the CLR host, and ManagedHost which is surprisingly enough the managed half of the host.

The COM interfaces that the two halves of the host use to communicate over are defined in ManagedHost as the imaginatively named IManagedHost and IUnmanagedHost. These interfaces are then exported to a type library with tlbexp, and imported into the native host with Visual C++'s #import directive.

The entry point to the application is wmain in ADMHost\ADMHost.cpp. The first thing that ADMHost does when it starts up is call CClrHost::BindToRuntime in order to load up the CLR. BindToRuntime just uses ATL to create a CClrHost object (which implements IUnmanagedHost), and returns that. As part of the construction process of CClrHost, we call CorBindToRuntimeEx telling it to bind to the latest CLR which can be hosted via the ICLRRuntimeHost interface. In practice this means that you'll get Whidbey for now, but when later releases of the CLR come out, you'll get them instead. v1.x of the CLR does not support ICLRRuntimeHost, so you won't ever bind to those versions.

Now that the entry point has an IUnmanagedHostPtr, it calls Start() to fire up the runtime. The Start call translates into a call to CClrHost::raw_Start which begins by validating that we've bound to a runtime and that the runtime has not yet started. It then asks the CLR to get it's IClrControl object which allows the host to tweak some knobs on the CLR. Similarly, it offers the CClrHost instance to the CLR as an IHostControl, which the CLR uses when it needs to tell the host to do something.

The first knob that we set on the CLR is the AppDomainManager by calling IClrControl::SetAppDomainManagerType, and passing in the name of the ManagedHost assembly and the AppDomainManager type. These are hard coded as constants CClrHost::AppDomainManagerAssembly and CClrHost::AppDomainManagerType on lines 4 and 5 of ClrHost.cpp, so if you rename the ManagedHost class or namespace, or rename, reversion, or sign the ManagedHost.dll with a new public key, you'll need to update the constants here as well. Once we've told the CLR what class implements our AppDomainManager, we can go ahead and tell it to startup by calling ICLRRuntimeHost::Start.

In the process of starting up the CLR, the default AppDomain is created. Since we told the CLR that ADMHost.ManagedHost was our AppDomainManager, as soon as this domain is created an instance of ManagedHost (ManagedHost\ManagedHost.cs) is created and InitializeNewDomain will be called. ManagedHost simply sets its InitializationFlags to AppDomainInitilizationOptions::RegisterWithHost. When InitializeNewDomain completes, the CLR checks the RegisterWithHost flag. Seeing that it has been set, the CLR calls IHostControl::SetAppDomainManager passing in the AppDomain ID and a pointer to the AppDomainManager for that domain.

The implementation of SetAppDomainManager that CClrHost provides (line 84 in ClrHost.cpp) first does a QueryInterface on the AppDomainManager, to convert it to an IManagedHost. Once it has the pointer to the IManagedHost, it calls IManagedHost::SetUnmanagedHost passing in a pointer to itself. The supplied AppDomainManager saves away this reference in the ManagedHost.unmanagedHost field, but doesn't actually use it. In a more complex hosting scenario, the AppDomainManager might use this reference to ask the unmanaged host to perform some service for it.

Note that we haven't returned from ICLRRuntimeHost::Start() yet. At this point, a conceptual callstack looks something like:

wmain()

IUnmanagedHostPtr::Start()

(IUnmanagedHost) CClrHost::raw_Start()

ICLRRuntimeHost::Start()

CLR Stack Frames

(IHostControl) CClrHost::SetAppDomainManager()

IManagedHost::raw_SetUnmanagedHost()

CLR Stack Frames

ADMHost.ManagedHost.SetUnmanagedHost()

After registering the unmanaged host with the AppDomainManager, SetUnmanagedHost saves the AppDomainManager reference in a STL map, indexed by it's AppDomain ID. When it does that, control flow will now wind back down the stack and back into the main routine.

At this point, the main function calls RunApplication located in ADMHost\ADMHost.cpp on line 10, passing it a reference to the IUnmanagedHost. If you wanted to customize this sample quickly, this method would be the only one you need to replace since it's where all application specific code would go.

RunApplication access the AppDomainManager of the default domain by getting the DefaultManagedHost property of the IUnmanagedHost. CClrHost::get_DefaultManagedHost simply calls IUnmanagedHost::GetManagedHost passing it an ID of 1, representing the default domain. CClrHost::raw_GetUnmanagedHost then accesses the STL map to get the specified AppDomainManager.

RunApplication tells the default managed host to create a second AppDomain, which is implemented in ManagedHost.cs as ManagedHost::CreateAppDomain. As you would expect this call does nothing more than call AppDomain.CreateDomain, returning the new domain's ID. When the domain is created, the CLR will call the new ManagedHost's InitializeNewDomain, which will again set the RegisterWithHost flag. This will cause CClrHost::raw_SetAppDomainManager to be called, and the new AppDomain will be added to the map. RunApplication then gets a reference to the new managed host, and calls Write having it echo "Hello World".

When RunApplication finishes, wmain calls Stop on the IUnmanagedHost reference. CClrHost::raw_Stop first iterates over each AppDomainManager in the STL map, calling Dispose on them. Note that this Dispose method was defined in IManagedHost. The CLR will not automatically dispose of an AppDomainManager even if it implements IDisposable. After the Dispose method is called on the AppDomainManagers, CClrHost stops the CLR itself, and the program terminates.

Customizing ADMHost

If you wanted to use ADMHost as a starting point for your application, the first thing you would want to do would be replace the keypair in ManagedHost\ManagedHost.snk with one that you generated yourself. (of course this means you'll also have to update the strong name of ManagedHost.dll on line 4 of ADMHost\ClrHost.cpp).

Next you'll want to customize the services that your managed and unmanaged hosts provide to each other by updating the IManagedHost and IUnmanagedHost interfaces in ManagedHost\IManagedHost.cs and ManagedHost\IUnmanagedHost.cs. For instance, you might want your managed host to expose a method that loads up an assembly containing the bulk of your application and starts it off. You would then implement these services by implementing IManagedHost on the ManagedHost class and implementing IUnmanagedHost on the CClrHost class. Notice that when Visual C++ #import's the IUnmanagedHost interface, it will mangle the names, so you'll be implementing methods named raw_Method() rather than just Method().

Finally, you'll want to replace the RunApplication method in ADMHost\ADMHost.cpp to actually perform the work of your application.

Wrapping Up

Although the ADMHost sample application doesn't do very much on it's own, it can be used as a starting point for an application that wishes to host the CLR and use an AppDomainManager. The application specific code is very isolated, and can easily be customized. I'll also be using this sample to demonstrate some other features that require interaction between managed and unmanaged code in a hosting environment.

A Closer Look at the Simple Sandboxed AppDomain

shawnfa — Tue, 09 Aug 2005 22:02:00 GMT

Yesterday we took a look at Whidbey's new Simple Sandboxing API. At first glance this API does seem relatively simple, however when you start to look closer at the AppDomain that is created for your sandboxed code, there are a few surprising properties.

You might expect that under the covers this API is doing the grunt work of creating an AppDomain policy level which grants AllCode the specified permission set, and then has a code group for each strong name specified on the FullTrust list in order to provide those assemblies FullTrust. However, this is not how the API works -- it actually uses an entirely different security model than the traditional policy level based one. In fact, there is no AppDomain policy level in the sandboxed domain at all! Instead the sandboxed domain simply keeps track of a set of FullTrust assemblies and a permission set to be granted to all other assemblies and the AppDomain itself. No policy resolution will be done for assemblies loaded into this type of domain.

Why does Whidbey add this second AppDomain security model? Aside from making it trivial for applications to sandbox untrusted code, it's also required for the ClickOnce security model. ClickOnce allows an application to specify the exact set of permissions it should run under. ClickOnce application authors test their applications with these permissions and expect to have exactly their requested permissions at runtime. This AppDomain security model allows for that to occur.

Similarly, Visual Studio's debug-in-zone feature also requires an environment where the permissions it requests are exactly the permissions it gets -- if it were to debug your application with fewer privileges, debug-in-zone could lead to a lot of confusion when operations that are expected to pass start throwing SecurityExceptions.

Finally lets take a look at that evidence parameter to the CreateDomain API. Since a sandboxed AppDomain does not resolve policy and always has a domain permission set equal to the grant set of the assemblies loaded into it, why does it need Evidence? Technically the domain itself doesn't need that parameter, and it won't ever look at it directly. However, the evidence is still stored on the AppDomain's Evidence property. This means that other features which make decisions based upon AppDomain evidence (such as isolated storage), can still work with code executing in a simple sandboxed domain without modification.

Setting up an AppDomainManager

shawnfa — Fri, 22 Jul 2005 03:34:00 GMT

When I first talked about AppDomainManagers, I mentioned that there were three ways to tell the CLR that you'd like to use the managed hosting infrastructure:

The unmanaged hosting API
Environment variables APPDOMAIN_MANAGER_ASM and APPDOMAIN_MANAGER_TYPE
A set of registry keys

Of these three, which one should you pick? Obviously the unmanaged hosting API is only available to you if you're willing to have an unmanaged component of your application. Of course if you do have an unmanaged component, and you want to have communication back and forth between the two halves, using this API and setting AppDomainManagerInitializationOptions.RegisterWithHost in your InitializeNewDomain method is a great way to get that setup.

If you're sticking with a purely managed application, that leaves you with the other two options. Given the choice between the two, you should almost always choose the environment variables over the registry keys.

The problem with the registry keys is that there's only one set of them for every application running under your user profile. This means that if your application chooses to set these keys it creates several different types of problems. First, every managed application that starts after the keys are set will use the AppDomainManager (unless they specify their own using one of the other two methods). Since those applications have not been tested running with your AppDomainManager, and AppDomainManagers are generally used to modify the behavior of the CLR, this will likely lead to all kinds of unpredictable behavior which will be very difficult to trace back to the source.

Even if your AppDomainManager is relatively inert and does not affect the other applications in any way, the fact that there is only one set of registry keys creates another problem. If two applications decide that they're going to setup their AppDomainManager using these keys during setup, you have an obvious problem. However, even if two applications provide a shim program to set the keys and then kick off their real code, you still have a race condition:

Application A sets the registry key for AppDomainManager A
Application B sets the registry key for AppDomainManager B
Application A starts with AppDomainManager B
Application B starts with AppDomainManager B

The world is great for Application B, however Application A probably is not going to run very well at all since the AppDomainManager it was depending upon is not running in its process.

On the other hand, environment variables are inherited from the parent process, and can be modified by each child. Since different processes can have separate environment blocks with the same environment variables having different values, you avoid all the race conditions above.

Incidentally, one question that comes up relatively often is why didn't we enable an application to specify its AppDomainManager in the .exe.config file? The reason is security -- every managed .exe can supply an .exe.config file. Since AppDomainManagers are so powerful, we didn't want to expose the ability to specify one to untrusted code. Instead, the only ways to set one up involve running managed code, having write access to the environment, or having write access to the registry. Since these are all trusted operations, fencing off the AppDomainManager to only applications that can perform them reduces the surface area for attack on this feature.

Whidbey's Security Off Model

shawnfa — Thu, 28 Apr 2005 17:03:00 GMT

Although the v1.0 and v1.1 versions of CasPol provided a switch to disable the CLR's security system, running without CAS enforcement on was never a scenario that we encouraged for obvious reasons. The choice to disable security was a system wide switch that affected any managed application on any version of the runtime, and made running managed code incredibly unsafe.

As of Whidbey, you'll find that the switch to turn security off no longer works as it used to. If you run caspol -s off with beta 2 or later of Whidbey installed, you'll see:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215>CasPol.exe -s off
Microsoft (R) .NET Framework CasPol 2.0.50215.44
Copyright (C) Microsoft Corporation. All rights reserved.

CAS enforcement is being turned off temporarily. Press <ENTER> when you want to
restore the setting back on.

Security will then be disabled as long as the CasPol process remains active. When CasPol is terminated, it returns security to the on state. Even abruptly terminating the CasPol process will still return security to its on state.

This works because the implementation of the internal security off flag has changed. Instead of using a registry key to indicate the status of CLR security, we now use a named mutex which CasPol holds to indicate to the CLR that it should disable security. Examining the the handles held by the CasPol process in a debugger will enable you to quickly identify this mutex:

0:000>!handle 0 4 Mutant
Handle 4c
  Name          \BaseNamedObjects\CLR_CASOFF_MUTEX
Handle 428
  Name          <none>
Handle 4a8
  Name          \BaseNamedObjects\ShimCacheMutex
Handle 624
  Name          <none>
4 handles of type Mutant

Since security is being disabled by this mutex, the CasPol process is resilient to being terminated unexpectedly, because Windows will just clean up the handle for CasPol when cleaning up the process. Another side effect is that if the machine is rebooted, the security state will revert to on.

If we fire up the kernel debugger, we can take a look at the ACL of the mutex:

lkd> !object \BaseNamedObjects\CLR_CASOFF_MUTEX
Object: 85088d88  Type: (8679f040) Mutant
    ObjectHeader: 85088d70
    HandleCount: 1  PointerCount: 2
    Directory Object: e179f980  Name: CLR_CASOFF_MUTEX

lkd> dt nt!_OBJECT_HEADER 85088d70
   +0x000 PointerCount     : 2
   +0x004 HandleCount      : 1
   +0x004 NextToFree       : 0x00000001
   +0x008 Type             : 0x8679f040
   +0x00c NameInfoOffset   : 0x10 ''
   +0x00d HandleInfoOffset : 0 ''
   +0x00e QuotaInfoOffset  : 0 ''
   +0x00f Flags            : 0x20 ' '
   +0x010 ObjectCreateInfo : 0x853e3678
   +0x010 QuotaBlockCharged : 0x853e3678
   +0x014 SecurityDescriptor : 0xe2c57b2c
   +0x018 Body             : _QUAD

lkd> ?? 0xe2c57b2c & ~0x7
unsigned int 0xe2c57b28

lkd> !sd e2c57b28 1
->Revision: 0x1
->Sbz1    : 0x0
->Control : 0x8004
            SE_DACL_PRESENT
            SE_SELF_RELATIVE
->Owner   : S-1-5-32-544 (Alias: BUILTIN\Administrators)
->Group   : S-1-5-21-2127521184-1604012920-1887927527-513 (Group: REDMOND\Domain Users)
->Dacl    :
->Dacl    : ->AclRevision: 0x2
->Dacl    : ->Sbz1       : 0x0
->Dacl    : ->AclSize    : 0x34
->Dacl    : ->AceCount   : 0x2
->Dacl    : ->Sbz2       : 0x0
->Dacl    : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[0]: ->AceFlags: 0x0
->Dacl    : ->Ace[0]: ->AceSize: 0x18
->Dacl    : ->Ace[0]: ->Mask : 0x001f0001
->Dacl    : ->Ace[0]: ->SID: S-1-5-32-544 (Alias: BUILTIN\Administrators)

->Dacl    : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[1]: ->AceFlags: 0x0
->Dacl    : ->Ace[1]: ->AceSize: 0x14
->Dacl    : ->Ace[1]: ->Mask : 0x001f0001
->Dacl    : ->Ace[1]: ->SID: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)

->Sacl    :  is NULL

That shows that the mutex is created with an ACL that prevents anyone who isn't an administrator from owning it. And although Windows does not provide a way to prevent non-administrators from creating this mutex, internally the CLR will not respect the existence of the named mutex if it is abandoned or not owned by the BUILTIN\Administrators group. This prevents a squatting attack where a malicious user could turn off security simply by creating this mutex himself.

One of the more interesting effects to note of disabling security with this mutex is that the v2.0 CLR will no longer respect the registry key used by older versions of the runtime, and those versions will not have their security disabled by the new CasPol switch.

Although there still is the ability to turn off security, the ability to turn it off permanently has been removed. The new switch is useful mostly for debugging purposes, to establish if a problem you're diagnosing is related to the security system or not. The recommendation is still to avoid using this mechanism if at all possible.

Safely Impersonating Another User

shawnfa — Wed, 23 Mar 2005 02:58:00 GMT

Yesterday I posted a bit of code that shows how to impersonate another user in managed code. However, that code had a subtle security hole waiting to bite you if you used it directly. Both Dean and Eric found the problem. In fact Eric reminded me of a blog entry he wrote on the same subject last fall.

The basic problem is that unlike most CLR security settings, impersonation is tied to the executing thread and not to the stack frame. This means that if malicious code sees that your code is going to impersonate a privileged user, and then call into a method that it can cause to throw an exception, that malicious code can catch the exception and be running as the privileged user in its exception handler.

Steve suggested wrapping the entire impersonate / Undo operation in a simple utility object that implements IDisposable. That way you could use the C# using construct and have the Dispose method undo impersonation if the stack frame was popped of during an exception unwind. At first brush this seems like a really good idea, however some deeper analysis shows that even this won't stop a determined malicious assembly.

How's that? CLR exception handling takes place in two passes. On the first pass, the CLR walks down the call stack checking for a frame willing to handle the exception. In C# this means that the type specified in your catch block matches the type of the exception. However, in VB or IL you can write an exception filter, which is a block of arbitrary code that executes to determine if the exception handler should run.

Once the stack frame containing the exception handler is identified, the CLR returns back to the top of the stack to begin its second pass of exception handling. On this step, finally and fault blocks are executed and then the frame is popped until the handling frame is reached.

So if we put our Undo call in the finally block, it won't get called until the second pass of exception handling. That means any malicious code that can execute on the first pass, by implementing an exception filter, will still run in the impersonated context, regardless of the best intentions of our finally block.

What's the solution? If you're coding in C#, the only way to be called on the first pass of exception handling is to actually catch the exception. That means that there is unfortunately nothing much more elegant than:

// Begin impersonating the user
WindowsImpersonationContext impersonationContext = WindowsIdentity.Impersonate(userHandle.Token);

try
{
    DoSomeWorkWhileImpersonating();
}
catch
{
    // Clean up
    if(userHandle != IntPtr.Zero)
    {
      CloseHandle(userHandle);
      userHandle = IntPtr.Zero;
    }

    if(impersonationContext != null)
    {
      impersonationContext.Undo();
      impersonationContext = null;
    }

    // allow the exception to continue on its way
    throw;
}
finally
{
    // Clean up
    if(userHandle != IntPtr.Zero)
      CloseHandle(userHandle);

    if(impersonationContext != null)
      impersonationContext.Undo();
}

Notice that we use a plain catch, since ECMA allows for objects not derived from Exception to be thrown. We also use a throw operation to cause the IL rethrow opcode to be emitted, which limits the amount of interfering we did with the exception handling process.

In VB you can be a little more slick and use an exception filter:

' Begin impersonating the user
WindowsImpersonationContext impersonationContext = WindowsIdentity.Impersonate(userHandle.Token)

Try

    DoSomeWorkWhileImpersonating()

Catch When UndoImpersonation(userHandle, impersonationContext) = False

    Debug.Assert(False, "CleanUp returned False")
Finally

    UndoImpersonation(userHandle, impersonationContext)
End Try

' ...

Private Function UndoImpersonation(ByRef userHandle As IntPtr, ByRef impersonationContext As WindowsImpersonationContext) As Boolean
  If Not IntPtr.Zero.Equals(userHandle) Then
    CloseHandle(userHandle)
    userHandle = IntPtr.Zero
  End If
  If impersonationContext <> Nothing Then
    impersonationContext.Undo()
    impersonationContext = Nothing
  End If
  Return True
End Function

Here, we undo the impersonation in the exception filter, but never actually catch the exception, since the filter will never evalutate to True. It's a nicer approach than the C# method, since by not catching the exception we make debugging a lot easier.

Both approaches are ugly, but in order to be safe you'll need to implement at least one. The lesson here is that coding when you don't necessarily trust your callers is difficult. Throw in the fact that exception safe coding is also difficult to do properly, and you've got yourself into a very tricky situation. Tomorrow, we'll look at using some new Whidbey features to make the whole process a lot nicer and safer.

Updated 3/23: Fixed double-free problem

When is ReflectionPermission Needed?

shawnfa — Tue, 08 Mar 2005 20:31:00 GMT

Reflection and its interaction with security can sometimes be a bit of a confusing matter. The easiest portion to figure out is the permissions needed to use Reflection.Emit. In order to do anything with the reflection emit feature, you'll need to have ReflectionPermission with the ReflectionEmit flag set. In the default policy, you'll have this permission if you're running on LocalIntranet or MyComputer.

Things get a little more dicey when you start to figure out what permissions you need in order to use standard reflection. The general rule of thumb is that if you could do something with early binding, then you won't need ReflectionPermission in order to use reflection to do the same thing with late binding. So, you could easily create an XmlDocument and load a string into it with the Load method via reflection, even if you didn't have any ReflectionPermission. This makes sense because demanding a permission here really doesn't buy any extra security, since you could have just done these operations directly in your code anyway.

Getting a Type object for a type that is not visible to you, or getting an object to represent a member that is not visible has different behavior between v1.x and v2.0. On v1.x, you'll need ReflectionPermission with the TypeInformation flag. This means if you want to get a Type object for System.AssemblyHandle (which is a type in mscorlib marked as internal), you'll need this permission. You'll also need this permission to get a MethodInfo object for System.Array::GetMedian() even though Array is public, since GetMedian() is a private member. The same holds true of getting a FieldInfo for System.Security.PermissionSet::m_Unrestricted, a private field. Getting a PropertyInfo for the protected property System.Security.Cryptography.HashAlgorithm::HashSize would not require any permissions if you derived from HashAlgorithm, otherwise TypeInformation would be needed there as well. One thing that's interesting to note about this is that if you do not have TypeInformation, and you try to perform one of these protected operations, you won't get a SecurityException. Instead, reflection will just return a null object back to you. In Whidbey the TypeInformation flag has been marked as obsolete, and any code can get at these objects.

The reason this is safe is that once you have the appropriate xxxInfo object, and you want to either invoke it or read its value, you'll need ReflectionPermission with the ReflectionPermissionFlag.MemberAccess flag set. By default, both TypeInformation and MemberAccess are only granted to code running on the local machine.

So, from the discussion above, it would seem that I could easily call System.Reflection.Assembly::GetExecutingAssembly() from partial trust code, since Assembly is a public class, and GetExecutingAssembly() is a public method on that class. However, if I tried to do that, I would end up with a SecurityException.

Why is that? The answer lies deep within the CLR, inside the reflection internals. If you look inside the SSCLI, you can find the code that's responsible for dispatching the late-bound call in COMMember::InvokeMethod_Internal (located in sscli\clr\src\vm\COMMember.cpp, line 1154). Scanning down a bit through that method, there's an interesting comment on line 1231, where the reflection system calls an IsDangerousMethod() function to check to see if it needs to demand additional permissions. If IsDangerousMethod() returns true, then an RM_ATTR_RISK_METHOD flag gets set, which causes COMCodeAccessSecurityEngine::SpecialDemand(REFLECTION_MEMBER_ACCESS) to be called on line 1278.

It seems pretty obvious that this might be our problem, so lets go check out IsDangerousMethod() to see what it considers to be dangerous. This function starts at line 1007 of COMMember.cpp, and the meat of it is between lines 1073 and 1093. Basically, we check the method table of the method in question, and compare it to a method table of several classes. If the method belongs to one of these classes, we consider it dangerous and return true. The list of classes to compare against is initialized on lines 1031 to 1049. The 19 special classes are:

System.Activator	System.AppDomain
System.RuntimeType	System.Type
System.IO.IsolatedStorage.IsolatedStorageFile	System.Reflection.Assembly
System.Reflection.ConstructorInfo	System.Reflection.EventInfo
System.Reflection.FieldInfo	System.Reflection.MethodBase
System.Reflection.PropertyInfo	System.Reflection.RuntimeConstructorInfo
System.Reflection.RuntimeEventInfo	System.Reflection.RuntimeFieldInfo
System.Reflection.RuntimeMethodInfo	System.Reflection.RuntimePropertyInfo
System.Reflection.Emit.AssemblyBuilder	Sytem.Reflection.Emit.MethodRental
System.Resources.ResourceManager

This table is defined in terms of macros that look like CLASS__APPDOMAIN, which should all be relatively easy to figure out on their own. However, if you'd like to find the source of this definition, you can check clr\src\vm\mscorlib.h, where all of these macros are created. For instance, CLASS__APPDOMIAN is created on line 64 of this file:
DEFINE_CLASS(APP_DOMAIN, System, AppDomain)

If a class belongs to this table, then none of its methods or properties are available through late binding unless the calling code is granted MemberAccess. That's why my partial trust code above couldn't call Assembly::GetExecutingAssembly().

In addition to the 19 classes listed above, Whidbey adds the following four classes to the dangerous list:

System.RuntimeFieldHandle	System.RuntimeMethodHandle
System.RuntimeTypeHandle	System.Reflection.RuntimeFieldInfo

Another area where reflection and security come together is when the target code is protected with a LinkDemand. The problem with using reflection to invoke a method that contains a LinkDemand is that the reflection code and not your code will ultimately be the method's caller. This means that if the LinkDemand is for a set of CAS permissions (FullTrust for instance), it may be satisfied by the reflection code which lives in mscorlib, even though the demand may not have been satisfied by your code. In order to prevent malicious code from circumventing LinkDemands through the use of reflection, invoking a method through reflection has the effect of turning LinkDemands into full demands. If you don't want the whole stack checked, then you should Assert the permissions being demanded before calling the method with reflection, and then RevertAssert those permissions after the method returns. By following that pattern, you can most closely simulate the effect of the LinkDemand.

For instance, if I'm calling System.Security.Cryptography.X509Certificates.X509Certificate::Handle, which has a LinkDemand on its getter for UnmanagedCode, I would use something like this:

IntPtr handleValue = IntPtr.Zero;
try
{
    new SecurityPermission(SecurityPermissionFlag.UnmanagedCode).Assert();
    handleValue = (IntPtr)handleProperty.GetValue(cert, null);
}
finally
{
    CodeAccessPermission.RevertAssert();
}

To sum up, when working with reflection, if you keep the following rules in mind, you shouldn't run into any issues:

If you're using Reflection.Emit, you need ReflectionPermissionFlag.Emit
If you're accessing code that you would be able to access anyway, you don't need any permission
If you're getting objects describing items you don't have access to, you need ReflectionPermissionFlag.TypeDiscovery
If you're invoking objects you don't have access to, you need ReflectionPermissionFlag.MemberAccess
There are some special classes unavailable without ReflectionPermissionFlag.MemberAccess
All LinkDemands will turn into full Demands

The Difference Between the Strong Name Hash and Hash Evidence

shawnfa — Tue, 01 Mar 2005 01:12:00 GMT

The System.Security.Policy.Hash class allows you to make security decisions based upon the hash of an assembly using the HashMembershipCondition. That sounds awfully similar to how strong names are calculated ... According to ECMA partition II section 6.2.1.3, a strong name is computed by using RSA to encrypt the SHA1 hash of the assembly. Taking those two statements together, one logical jump to make would be that we could take an assembly's private key and use it to sign the value of the Hash.SHA1 property, creating the assembly's signature ourselves.

However, that wouldn't work as expected. The value generated by Hash.SHA1 is a hash over every bit that makes up the assembly, whereas the hash used to create the strong name signature actually skips over portions of the assembly's PE image. We can see this from looking up the strong name signature algorithm in the SSCLI source -- the function in question is named ComputeHash(); it begins on line 1964 of sscli\clr\src\dlls\mscorsn\strongname.cpp.

Following ComputeHash() along, after adding the the DOS header to the hash on lines 1978-1979, we move on to the NT headers. Here we encounter the first section of the assembly that gets skipped. In the OptionalHeaders, we zero out the checksum as well as the security data directory, which is used for Authenticode signing, before adding their values into the hash.

The reason for this is that we want the Authenticode signature to envelope the strong name signature instead of the other way around. If we left these entries in place, providing an Authenticode signature for the assembly would change these values, invalidating our hash and thus the strong name signature.

Once the headers are hashed, lines 2004-2028 are responsible for computing the hash of the sections within the PE file. Again, you'll notice that we don't hash every byte here -- before adding a section to the hash, we need to check to see if the strong name blob falls within that section. If not we can hash the entire section, however if it does, we hash everything but the blob itself ... effectively removing it from our view of the assembly. This step is obviously necessary, since once the signature is computed, writing it into the assembly will change the contents of that blob, and if it was part of the hash would immediately render the signature invalid.

Hash.SHA1 doesn't have any of these restrictions since the primary reason to use this class is to enable the HashMembershipCondition in policy. At policy evaluation time, the assembly has already been signed with a strong name key and certificate (if it was going to be signed at all), so we don't need to skip the Authenticode directory entry. Additionally, since the value computed by Hash is never written back to the assembly, we don't have to worry about skipping any space for it to be written to.

In summary, Hash.SHA1 is a hash over every byte in the assembly, whereas the SHA1 hash used in the signing process:

Hashes the DOS headers if they exist
Hashes the NT headers, after zeroing out the checksum and Authenticode directory entry
Hashes each section of the PE file, skipping over the location where the signature will eventually be stored

Finding the Raw Strong Name Signature

shawnfa — Wed, 26 Jan 2005 23:11:00 GMT

Wow ... there's been lots of interest in signatures lately :-) In response to my last post about reserving a larger section of the PE file for the signature when you create a signature with a larger key, William wants to know if you can extract the actual signature bytes from the PE file.

Absolutely you can, it's even relatively easy to do. Boiled down, the raw strong name signature is simply the array of bytes that are located at the RVA specified by the StrongNameSignature.VirtualAddress field of the CLR header. The signature length is specified by the StrongNameSignature.Size field of the header. So once you have the CLR header of a PE file, its very easy to find the signature itself.

In the spirit of picking the right tool for the job, I'll show how to do this in C++ code, since creating P/Invoke declarations for the various structures needed would take up a large chunk of time. The code for a method that takes a memory mapped PE file and displays its raw signature would look something like this:

1  /// <summary>
2  ///     Display the raw strong name signature of a memory mapped assembly
3  /// </summary>
4  HRESULT DisplaySignature(BYTE *pbFile)
5  {
6      _ASSERTE(pbFile != NULL);
7      _ASSERTE(0 < cbFile);
8  
9      PIMAGE_NT_HEADERS pNtHeader = ImageNtHeader(pbFile);
10      if(NULL == pNtHeader)
11      {
12          std::cout << "Error: Could not get NT headers for file" << std::endl;
13          return E_INVALIDARG;
14      }
15  
16      // find the data directories in the file
17      PIMAGE_DATA_DIRECTORY pDataDirectories = NULL;
18      switch(pNtHeader->OptionalHeader.Magic)
19      {
20          case IMAGE_NT_OPTIONAL_HDR32_MAGIC:
21              pDataDirectories = reinterpret_cast<PIMAGE_NT_HEADERS32>(pNtHeader)->OptionalHeader.DataDirectory;
22              break;
23  
24          case IMAGE_NT_OPTIONAL_HDR64_MAGIC:
25              pDataDirectories = reinterpret_cast<PIMAGE_NT_HEADERS64>(pNtHeader)->OptionalHeader.DataDirectory;
26              break;
27          
28          default:
29              return E_NOTIMPL;
30      }
31      
32      // Make sure there is a CLR header
33      _ASSERTE(pDataDirectories != NULL);
34      if(0 == pDataDirectories[IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR].VirtualAddress ||
35         0 == pDataDirectories[IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR].Size)
36      {
37          std::cout << "Error: No CLR header" << std::endl;
38          return E_INVALIDARG;
39      }
40      
41      // get the CLR header
42      PIMAGE_COR20_HEADER pCorHeader = reinterpret_cast<PIMAGE_COR20_HEADER>(
43          ImageRvaToVa(
44              pNtHeader,
45              pbFile,
46              pDataDirectories[IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR].VirtualAddress,
47              NULL));
48      if(NULL == pCorHeader)
49      {
50          std::cout << "Error: Could not get CLR header" << std::endl;
51          return E_INVALIDARG;
52      }
53  
54      // check to see if there is a signature
55      if( 0 == pCorHeader->StrongNameSignature.VirtualAddress || 
56          0 == pCorHeader->StrongNameSignature.Size)
57      {
58          std::cout << "Error: Image is not signed" << std::endl;
59          return S_FALSE;
60      }
61  
62      // pull the signature from the header
63      BYTE *pbSignature = reinterpret_cast<BYTE *>(
64          ImageRvaToVa(
65              pNtHeader,
66              pbFile,
67              pCorHeader->StrongNameSignature.VirtualAddress,
68              NULL));
69      if(NULL == pbSignature)
70      {
71          std::cout << "Error: Could not find signature directory" << std::endl;
72          return E_INVALIDARG;
73      }
74  
75      // display it
76      std::cout << "Strong name signature (" << pCorHeader->StrongNameSignature.Size << " bytes):";
77      std::cout << std::hex;
78      for(DWORD i = 0; i < pCorHeader->StrongNameSignature.Size; i++)
79      {
80          if(i % 16 == 0)
81              std::cout << std::endl;
82          std::cout << std::setw(2) << (DWORD)(pbSignature[i]) << " ";
83      }
84      
85      std::cout << std::dec << std::endl;
86      return S_OK;
87  }

OK, that's a chunk and a half of code right there. However, the process its following is relatively straight forward. On lines 9-14, I use the DbgHelp function ImageNtHeader to locate the IMAGE_NT_HEADERS structure in the file. Once we have the NT headers, we need to find the data directories, but their location varies depending upon if the assembly is a PE32 or PE32+ file. So on lines 16 through 30 we check the magic number in the beginning of the optional header, and get the correct pointer to the data directories. If the PE is neither of these two formats, we bomb out.

So now that we've got the table of directory entries, on lines 32 through 52 we make sure that the entry for the COM descriptor directory exists, and if it does use another DbgHelp function ImageRvaToVa in order to convert the RVA of the directory entry to an address within the mapped file. The beginning of this directory entry is the CLR header, in the form of a IMAGE_COR20_HEADER structure.

Once we have our IMAGE_COR20_HEADER, the information about the signature is located in the StrongNameSignature field. In lines 54-73 we check if a signature exists, and if it does, use ImageRvaToVa in order to calculate the location in the file of the signature itself.

Once we have that offset, dumping the signature to the display is easy. Lines 75-83 simple iterate over the memory in the memory mapped file that contains the signature until we've dumped out pCorHeader->StrongNameSignature.Size bytes. At that point, we've displayed the entire signature, so the method returns.

Shri Starts Blogging

shawnfa — Tue, 25 Jan 2005 21:59:00 GMT

Shri started up a blog today, joining David as members of the JIT team on MSDN blogs. His first post is on how the x86 JIT implements a tail call ... and why its not as fast as it could be. Now that Shri has a blog, the percentage of people in my hallway that are blogging has overcome the percentage of people without MSDN blogs :-)