.NET Security Blog : Windows

Disabling the FIPS Algorithm Check

shawnfa — Fri, 14 Mar 2008 17:00:23 GMT

.NET 2.0 introduced a check for FIPS certified algorithms if your local security policy was configured to require them. This resulted in algorithms which are not FIPS compliant (or implementations which were not FIPS certified) throwing an InvalidOperationException from their constructors.

In some cases this isn't a desirable behavior. For instance, some applications need to use the MD5 hashing algorithm for compatibility with an older communication protocol or file format. Prior to .NET 3.5, the AES algorithm was only available in an implementation which was not FIPS certified, and if you needed to use that algorithm the FIPS check could also block you.

To help these cases, we added a configuration file switch to .NET 2.0 SP 1 (and therefore .NET 3.5) which allows an application to say "I know what I'm doing, please don't enforce FIPS for me". For these applications, they can setup a configuration file similar to:

<configuration>

    <runtime>

        <enforceFIPSPolicy enabled="false"/>

    </runtime>

</configuration>

Which will prevent the CLR from throwing InvalidOperationExceptions from the constructor of uncertified algorithms and implementations.

Which Groups Does WindowsIdentity.Groups Return?

shawnfa — Thu, 07 Feb 2008 20:00:45 GMT

WindowsIdentity exposes a Groups property which returns a collection of IdentityReferences for the groups that a particular user is a member of. However, if you look closely, you'll find that these returned groups won't necessarily include all of the groups that the user is a member of.

Under the covers, WindowsIdentity populates the groups collection by querying Windows for information on the groups that the user token is a member of. However, before returning this list, the Groups property filters out some of the returned groups.

Specifically, any groups which were on the token for deny-only will not be returned in the Groups collection. Similarly, a group which is the SE_GROUP_LOGON_ID will not be returned.

Generally, this is exactly the behavior you want. For instance, if your application is going allow a specific action because the user is a member of a group, you don't want to allow it if the user is a member of the group for deny-only.

If you want to retrieve all of the groups however, there's not an easy built-in way for you to do this. Instead, you'll have to P/Invoke to the GetTokenInformation API to retrieve the groups yourself.

It can be interesting to dump out the groups that specific users are part of -- here's a simple little snippet of code that does just that. (And uses some of those fancy new C# 3.0 features to display them grouped by domain):

    public static void Main()
    {
        using (WindowsIdentity currentIdentity = WindowsIdentity.GetCurrent())
        {                
            var groups = // Get all of the groups from our account, and translate them from IdentityReferences to NTAccounts   
                        from groupIdentity in currentIdentity.Groups
                        where groupIdentity.IsValidTargetType(typeof(NTAccount))
                        select groupIdentity.Translate(typeof(NTAccount)) as NTAccount into ntAccounts
 
                        // Sort the NTAccounts by their account name
                        let domainName = ntAccounts.GetDomainName()
                        let groupName = ntAccounts.GetAccountName()
                        orderby domainName
 
                        // Group the sorted accounts by the domain they belong to, and sort the grouped groups by domain name
                        group ntAccounts by domainName into domainGroups
                        orderby domainGroups.Key
                        select domainGroups;
 
            foreach (var domainGroups in groups)
            {
                Console.WriteLine("Groups from domain: {0}", domainGroups.Key);
 
                foreach (var group in domainGroups)
                {
                    Console.WriteLine("    {0}", group.GetAccountName());
                }
            }
        }
    }
 
    private static string GetDomainName(this NTAccount account)
    {
        string[] split = account.Value.Split('\\');
        return split.Length == 1 ? String.Empty : split[0];
    }
 
    private static string GetAccountName(this NTAccount account)
    {
        string[] split = account.Value.Split('\\');
        return split[split.Length - 1];
    }

Using the MMC Snap-In to Configure 64 Bit CAS Policy

shawnfa — Thu, 15 Mar 2007 19:51:47 GMT

The .NET Framework SDK ships with a MMC Snap-In which enables you to, among other things, avoid using caspol to modify your local security policy.

Since each runtime installed on your machine has independent security policy, the MMC Snap-In will only modify policy for the version of the CLR it is running against, and you may need to have multiple MMC sessions to change the various versions of policy on your machine.

This is pretty obvious when it comes to changing the v1.1 policy vs changing the v2.0 policy, you just choose the correct link from Control Panel. However, things get a lot trickier when it comes to configuring v2.0 32 bit policy vs v2.0 64 bit policy.

The snap-in only modifies the security policy of the runtime that it is running against. Since the snap-in itself is running within the MMC process, this means that the policy that is being changed depends on the bitness of the MMC process. (Remember a 32 bit process cannot load 64 bit components, and vice-versa). Since the snap-in is processor neutral, it will happily load in both a 32 and 64 bit MMC -- leading to the surprising result that running the version of the snap-in that ships with the 64 bit SDK in a 32 bit MMC will result in changes to the 32 bit policy, not the 64 bit one.

Further muddying the waters is the fact that MMC has somewhat surprising behavior when launching it from the command line. One of our testers put together this table to help figure out which bitness of MMC is being launched:

Command	Bitness
%WinDir%\System32\mmc.exe	64
%WinDir%\SysWOW64\mmc.exe	64
%WinDir%\System32\mmc.exe <sdk_path>\bin\mscorcfg.msc	32
%WinDir%\SysWOW64\mmc.exe <sdk_path>\bin\mscorcfg.msc	32
%WinDir%\System32\mmc.exe /32 <sdk_path>\bin\mscorcfg.exe	32
%WinDir%\SysWOW64\mmc.exe /32 <sdk_path>\bin\mscorcfg.exe	32
%WinDir%\System32\mmc.exe /64 <sdk_path>\bin\mscorcfg.exe	64
%WinDir%\SysWOW64\mmc.exe /64 <sdk_path>\bin\mscorcfg.exe	64

MMC will actually occasionally terminate the version that you stared and relaunch a verison with a different bitness (details can be found here). What this means is that it doesn't really matter if you launch the 32 or 64 bit version directly when using the .NET Configuration Snap-In. Instead, you should be sure to pass the /32 or /64 command line switch to MMC in order to ensure that you get the version that you intend.

Kenny Kerr Explores UAC

shawnfa — Tue, 10 Oct 2006 18:29:00 GMT

Kenny Kerr, one of our Security MVPs, has updated his Windows Vista for Developers series with Part4 - User Account Control. Kenny takes an in-depth look at what UAC means for developers and covers areas that a lot of other sources don't touch on, such as integrety levels. This is absolutely worth a read once you begin to write software for Vista. (As are the rest of the articles in his series).

Adding a UAC Manifest to Managed Code

shawnfa — Thu, 06 Apr 2006 17:00:00 GMT

The UAC feature of Vista is one of my favorite new features -- it really makes running as a non-admin much less painful than it has been in the past. One of the requirements that UAC puts on developers is that we must mark our applications with manifests which declare if the application would like to run elevated or not. Documentation for this manifest format can be found on MSDN, where you can find the schema and information about what the various settings mean.

If you'd like to add one of these manifests to your managed application, the steps are relatively straight forward:

Create a manifest resource
Compile the resource
Embed it in your application

1. Create a manifest resource

The first step is to create a resource file containing your manifest. The manifest should be of type RT_MANIFEST, and have id 1 for an exe (id 2 for a dll). For instance, the resource script for an exe that does not need to elevate might be saved in UacManifest.rc and look like this:

#include <winuser.h>
#define IDR_MANIFEST 1 // 2 for a DLL

IDR_MANIFEST RT_MANIFEST MOVEABLE PURE
{
    "<assembly xmlns=""urn:schemas-microsoft-com:asm.v1"" manifestVersion=""1.0"">
       <asmv3:trustInfo xmlns:asmv3=""urn:schemas-microsoft-com:asm.v3"">
         <asmv3:security>
           <asmv3:requestedPrivileges>
             <asmv3:requestedExecutionLevel
               level=""asInvoker""
               uiAccess=""false"" />
           </asmv3:requestedPrivileges>
         </asmv3:security>
       </asmv3:trustInfo>
     </assembly>"
}

2. Compile the resource

You'll need to install the Platform SDK for this step so that you have access to the rc tool and the winuser.h header. Once you've gotten the SDK setup, you can then compile your resource script into a .res file:

C:\src\App>rc.exe UacManifest.rc

Which will create a UacManifest.res for you.

3. Embed it in your application

Now that you've compiled your .res file, you can pass it to your managed compiler when building your application to embed in your exe. The exact switch will vary depending on your compiler:

Compiler	Switch
C#	/win32res
VB	/win32resource
ILAsm	/resource
AL	/win32res

You can also select the resource file in the project properties in Visual Studio.

Return of the Mailbag

shawnfa — Tue, 21 Mar 2006 23:17:00 GMT

Over the last week or so I've seen a few questions pop up multiple times. In no particular order:

Q: Is calling a virtual method with a non-virtual call verifiable?

A: It depends :-) In v1.x of the CLR this was verifiable. We made a change in v2.0 which disallows a non-virtual call to a virtual method. Joe Duffy has a good writeup about this change and why we made it on his blog. Note that going the other way is verifiable -- using a callvirt to call a non-virtual function works just fine. In fact ildasm shows that the C# compiler always emits a callvirt regardless of the target being virtual or not.

Q: I want to create a signature using RSA and SHA-256, is that possible with the managed classes?

A: Not as of v2.0. The fundamental problem is that our only RSA implementation, RSACryptoServiceProvider, uses CAPI to do its work. However our only SHA-256 implementation, SHA256Managed is unknown to CAPI. This is on our radar for the next CLR release though.

Q: Is there any way to use ADMHost with a WinForms app so that the console window doesn't show up?

A: Sure. The underlying issue here is that in Windows, a PE image has its subsystem burned into its IMAGE_OPTIONAL_HEADER. Generally this is one of IMAGE_SUBSYSTEM_CUI or IMAGE_SUBSYSTEM_GUI ... although there are other options (they're listed under the comment "subsystem values" in winnt.h of the platform SDK if you're interested). Applications with a CUI subsystem always run with a console, weather or not they use it. (Windows has no way of knowing ahead of time if you do plan on using it or not). The opposite is true of GUI apps, which by default will not have a console window.

ADMHost.exe by default is compiled as a console application, using the CUI subsystem. Switch it to a Windows application and the console will go away. You can do this in the ADMHost.exe properties -- change the subsystem type to Windows.

Impersonation and Exception Filters in v2.0

shawnfa — Fri, 03 Mar 2006 18:00:00 GMT

A while back, I wrote about a potential security hole when malicious code can set up an exception filter before calling your code which does impersonation.

In the final release of v2.0, we've added a feature to help mitigate this problem. The CLR records that you've begun impersonation on the stack frame where you make the call to Impersonate(). If an exception is thrown, when the CLR walks the call stack looking for handlers, it will see this note and revert the impersonation when it moves past the frame.

This means that the following sample from my previous post would just work under v2.0:

public void SomeApi()
{
    // Call LogonUser to get a token for the user
    IntPtr userHandle = IntPtr.Zero();
    bool loggedOn = LogonUser(
        user,
        domain,
        password,
        LogonType.Interactive,
        LogonProvider.Default,
        out userHandle);
    if(!loggedOn)
        throw new Win32Exception(Marshal.GetLastWin32Error());

    // Begin impersonating the user
    WindowsImpersonationContext impersonationContext = null;
    try
    {
        WindowsIdentity.Impersonate(userHandle.Token);
        DoSomeWorkWhileImpersonating();
    }
    finally
    {
        // Clean up
        CloseHandle(userHandle);
        if(impersonationContext != null)
            impersonationContext.Undo();
    }
}

When the call to Impersonate() is made, the CLR notes that on SomeApi()'s stack frame and if DoSomeWorkWhileImpersonating() happens to throw, the impersonation is reverted before any callers of the SomeApi() have their exception filters run.

Note that since this state is tied to the stack frame, you won't get this benefit if you impersonate in one method and revert in another:

public void SomeOtherApi()
{

    // Begin impersonating the user
    WindowsImpersonationContext impersonationContext = null;
    try
    {
        impersonationContext = BeginImpersonating();
        DoSomeWorkWhileImpersonating();
    }
    finally
    {
        // Clean up
        if(impersonationContext != null)
            impersonationContext.Undo();
    }
}

Here, the impersonation is done in the BeginImpersonating() method, but is reverted in SomeOtherApi(). In this case, the stack frame for BeginImpersonating() is gone if DoSomeWorkWhileImpersonating() throws an exception. Since the BeginImpersonating() stack frame is the one which contained the annotation that impersonation needed to be undone, you lose the automatic revert behavior.

Obviously getting the undo for free is a much better option than having to go through all the work of protecting your code manually, so as you begin upgrading your code to run with v2.0 of the framework, you might want to look for places where you don't both impersonate and undo the impersonation in the same method.

UAC Policy Settings

shawnfa — Fri, 27 Jan 2006 19:23:00 GMT

The new UAC blog (formerly LUA, formerly UAP) has up a good post on the six security policy settings that have been introduced to control how UAC works. As the Vista betas start coming out and people can start to play with UAC, knowing that some of these knobs are available can certainly be helpful.

I've been spending time lately driving putting UAC manifests in all of the CLR tools, so I've got a bit of experience with this feature. It's certainly much easier to use than running as non-admin today, and is something that I can see being able to teach non-techie people how to use properly. From my experience, I think the security setting that's going to be most interesting is number six, "Virtualize file and registry write failures to per-user locations".

I'm sure the UAC blog is going to have future posts on virtuilization and how it works, and not being on that team I'm not going to cover those details. However, virtuilization can have some interesting and unexpected side effects, so if you've found that the applications that work on your machine can run without virtuilization it might be one option to consider turning it off.

PrincipalPermission and Finalizers

shawnfa — Mon, 09 Jan 2006 22:30:00 GMT

Nicole Calinoiu, one of our developer security MVPs, has just posted a good description of the problems that occur when using PrincipalPermission with impersonation and finalizers. The key thing to take away from this is that impersonation occurs on a per-thread basis and finalizers run on a thread that the GC controls, not on the main thread of your application. This means that if you're impersonating on your application's thread, your finalizers will not run under the impersonated context.

While Nicole gives a general solution to the problem, she also points out that if you're doing something that requires impersonation on the finalizer thread you might want to think about the design of your class. Definitely worth a read.

Mike Rousos on Registry Security

shawnfa — Mon, 09 Jan 2006 20:35:00 GMT

Over the weekend, Mike Rousos (a BCL tester who's been temporarily drafted onto the security team) posted an interesting piece about the new BCL registry security support on the BCL blog. While the title mentions RegistryPermission, the post is actually about the NT security features of the registry classes rather than CAS permissions. Mike covers the difference between RegistryRights and RegistryPermissionCheck -- two features that are nice additions to the BCL registry support. Worth checking out if you spend much time working with NT security on the registry.

Adding SignatureProperties to SignedXml

shawnfa — Thu, 03 Nov 2005 23:48:00 GMT

One of the optional portions of the W3C XML digital signature specification allows for a set of SignatureProperties to be assigned to a signature. SignatureProperties allow the signer to place some metadata into the signature itself, such as the time the signature was created and the name of the person creating the signature. Since the XML digital signature specification does not lay out specific properties, you are free to create as many domain specific properties as you'd like. Although the SignedXml class does not support this feature, it's easy enough to add on your own by deriving from the default SignedXml implementation.

Signature properties exist as a SignatureProperties element in the signature itself, embedded as a DataObject. The signature's references contain a pointer to this element with a Type of "http://www.w3.org/2000/02/xmldsig#SignatureProperty", as specified in the W3C spec. The SignatureProperties element will contain as many SignatureProperty elements as needed. Each SignatureProperty will have a Target pointing to the signature that we're creating and will contain arbitrary XML (which should be in a different namespace to be valid).

In order to implement this, we'll first create a SignaturePropertiesSignedXml class which derives from SignedXml and takes the typical XmlDocument constructor parameter, as well as an ID for the signature (which is needed for the SignatureProperty Target attribute), and the ID of the SignatureProperties element itself (which is needed for the reference to work). We then use this information to create the SignatureProperties element, and place it into a DataObject. Finally we create and add the reference to the SignatureProperties element:

/// <summary>
/// XML signature class which enables SignatureProperties
/// </summary>
public sealed class SignaturePropertiesSignedXml : SignedXml
{
    private XmlDocument doc = null;
    private XmlElement signaturePropertiesRoot = null;
    
    /// <summary>
    /// Create a SignedXml class which can have SignatureProperties
    /// </summary>
    /// <param name="doc">XML document the signature belongs in</param>
    /// <param name="signatureId">ID of the signature to create</param>
    /// <param name="propertiesId">ID of the SignatureProperties to create</param>
    public SignaturePropertiesSignedXml(XmlDocument doc, string signatureId, string propertiesId) : base(doc)
    {
        if(String.IsNullOrEmpty(signatureId))
            throw new ArgumentException("signatureId cannot be empty", "signatureId");
        if(String.IsNullOrEmpty(propertiesId))
            throw new ArgumentException("propertiesId cannot be empty", "propertiesId");
        
        this.doc = doc;
        Signature.Id = signatureId;
        
        // create a root element to hold the properties
        signaturePropertiesRoot = doc.CreateElement("SignatureProperties", XmlDsigNamespaceUrl);
        signaturePropertiesRoot.SetAttribute("Id", propertiesId);
        
        // create a data object for the properties to go into
        DataObject signatureProperties = new DataObject();
        signatureProperties.Data = signaturePropertiesRoot.SelectNodes(".");
        AddObject(signatureProperties);

        // and add a reference to the data object
        Reference propertiesRef = new Reference("#" + propertiesId);
        propertiesRef.Type = "http://www.w3.org/2000/02/xmldsig#SignatureProperty";
        AddReference(propertiesRef);
        
        return;
    }

Now that the constructor has done the work of setting up the signature properties, we'll need a simple method to add individual properties. This is easily accomplished by taking the XML content of the property, creating a SignatureProperty element with a Target of the containing signature, and adding the input XML to the SignatureProperty:

    /// <summary>
    /// Add a signature property to the document
    /// </summary>
    /// <param name="content">XML contents of the property</param>
    public void AddProperty(XmlElement content)
    {
        if(content == null)
            throw new ArgumentNullException("content");
        if(String.Compare(content.NamespaceURI, XmlDsigNamespaceUrl) == 0)
            throw new InvalidOperationException("Signature properties must not be in the XML Digital Signature namespace");

        // wrap the content in a SignatureProperty element
        XmlElement property = doc.CreateElement("SignatureProperty", XmlDsigNamespaceUrl);
        property.SetAttribute("Target", "#" + Signature.Id);
        property.AppendChild(content);

        signaturePropertiesRoot.AppendChild(property);
        return;
    }

Finally, we need to override GetIdElement (see my previous post on doing this for more information), since the default GetIdElement implementation does not search DataObjects and we have a reference that points to our SignatureProperties which is contained within a DataObject. In the override, we just check to see if we're searching for the signature properties, and if not fall back to default behavior.

    /// <summary>
    /// Get an element refered to by its ID
    /// </summary>
    /// <param name="doc">XML document to search for the element in</param>
    /// <param name="id">element to search for</param>
    /// <returns>Element with the given ID, null if it could not be found</returns>
    public override XmlElement GetIdElement(XmlDocument doc, string id)
    {
        if(id == null)
            return null;
        
        // see if this is the signature properties being referenced, otherwise fall back to default behavior
        if(String.Compare(id, signaturePropertiesRoot.GetAttribute("Id"), StringComparison.OrdinalIgnoreCase) == 0)
            return signaturePropertiesRoot;
        else
            return base.GetIdElement(doc, id);
    }

And that's it! We can now pretty easily use this class to add metadata to the signature. For example:

        XmlDocument doc = new XmlDocument();
        doc.Load("order.xml");
        SignaturePropertiesSignedXml signer = new SignaturePropertiesSignedXml(doc, "orderSignature", "signatureProperties");

        RSA key = new RSACryptoServiceProvider();
        signer.SigningKey = key;

        // create a timestamp property
        XmlElement timestamp = doc.CreateElement("TimeStamp", "http://www.example.org/#signatureProperties");
        timestamp.InnerText = DateTime.Now.ToUniversalTime().ToString();
        signer.AddProperty(timestamp);

        // create a signed by property
        XmlElement signedBy = doc.CreateElement("SignedBy", "http://www.example.org/#signatureProperties");
        signedBy.InnerText = new WindowsPrincipal(WindowsIdentity.GetCurrent()).Identity.Name;
        signer.AddProperty(signedBy);

        Reference orderRef = new Reference("");
        orderRef.AddTransform(new XmlDsigEnvelopedSignatureTransform());
        signer.AddReference(orderRef);

        signer.ComputeSignature();
        doc.DocumentElement.AppendChild(signer.GetXml());
        doc.Save("order-signed.xml");

Will produce a signature that contains the time and person who signed the document:

  <Signature Id="orderSignature" xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
      <Reference URI="#signatureProperties" Type="http://www.w3.org/2000/02/xmldsig#SignatureProperty">
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
        <DigestValue>KfpRjNAGP47ZKX/RZ9hFEpKo9u8=</DigestValue>
      </Reference>
      <Reference URI="">
        <Transforms>
          <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
        </Transforms>
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
        <DigestValue>BPoz+CmKZyTATOhskqke3iOXmvA=</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>CmMm ... JKU=</SignatureValue>
    <Object>
      <SignatureProperties Id="signatureProperties">
        <SignatureProperty Target="#orderSignature">
          <TimeStamp xmlns="http://www.example.org/#signatureProperties">11/3/2005 9:35:37 PM</TimeStamp>
        </SignatureProperty>
        <SignatureProperty Target="#orderSignature">
          <SignedBy xmlns="http://www.example.org/#signatureProperties">REDMOND\ShawnFa</SignedBy>
        </SignatureProperty>
      </SignatureProperties>
    </Object>
  </Signature>

To verify this signature you don't even have to use the custom SignaturePropertiesSignedXml class -- since the SignatureProperties element is now a child of the XML document (since we made this an enveloped signature), the standard SignedXml class will be able to find it to verify the signature.

Enforcing FIPS Certified Cryptography

shawnfa — Mon, 16 May 2005 19:06:00 GMT

Certain types of software, such as code written for a government contract, require adhering to a strict set of guidelines, especially when it comes to security. To better enable this type of software, v2.0 of the CLR provides the ability for you to enforce that only cryptograhic algorithms that have been FIPS 140-1 certified can be used. Even if you're not developing government applications, it's good to prepare your application for a new exception that could result from creating a crypto object.

On Windows XP and higher this switch, which showed up for the first time in beta 2, is settable via Windows security settings or the registry. To enable the setting in the Windows security settings, you should set the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security option to enabled.

In the registry, you can toggle this switch on by setting the DWORD FIPSAlgorithmPolicy under HKLM\System\CurrentControlSet\Control\Lsa to be equal to 1.

After enabling this seting, only cryptographic algorithms which are FIPS compliant will be allowed to be created in your managed applications. As a general rule of thumb, this means that none of the *Managed algorithms can be created, but you can create the *CryptoServiceProvider algorithms. Lets take a look at some quick sample code:

try
{
    MD5 md5 = new MD5CryptoServiceProvider();
    Console.WriteLine("Created algorithm");
}
catch(Exception e)
{
    Console.WriteLine(e);
}

If this code is run with the FIPS setting disabled, you'll see "Created algorithm" printed to the console as you would expect. However, if the code is run with FIPS enforcement enabled, you'll get an InvalidOperationException:

System.InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.

Note that you'll get this exception no matter how you attempt to create the algorithm. That means that even if you don't directly construct the alogrithm, but instead attempt to use one of the various Create() methods, you'll still be blocked.

Before enabling this setting, you should be aware that it will affect your entire system. So any managed application running on the v2.0 framework which attempts to use a cryptographic algorithm that is not FIPS compliant will throw the InvalidOperationException. Additionally, this setting affects other parts of Windows, including SSL/TLS in both IE and IIS, Terminal Server, and EFS.

Forcing Security to Stay On

shawnfa — Wed, 04 May 2005 20:11:00 GMT

Last time we looked at how the Whidbey version of CasPol uses a mutex to indicate the state of the security system. One of the more interesting fallouts from this model is that is that we can actually use this information to prevent security from being turned off in the first place.

As I mentioned in the last post, the CLR looks for a mutex named \BaseNamedObjects\CLR_CASOFF_MUTEX, and if this mutex exists, is not abandoned, and is owned by the BUILTIN\Administrators group, it considers security to be in an off state. The obvious CasPol -s off implementation given that information is to acquire the named mutex and set the ACL such that the CLR will recognize it. From there, it's pretty easy to see that in order to prevent CasPol from successfully turning off security, we need to prevent it from acquiring the mutex.

How would we go about doing that? According to the MSDN documentation, if CreateMutex is called with a non-NULL lpName parameter, it will return either a new mutex with the given name, or if the mutex already exists, it will return a handle to the existing object while setting the last error to ERROR_ALREADY_EXISTS. Basically that's saying that Windows only allows one mutex with a given name on each system.

This means that if we create the mutex before CasPol does, we'll have a handle to the same mutex that CasPol and the CLR use to determine the security state. If we're on Windows NT, we can make use of the Windows security system to prevent anyone else from having access to that object. For CasPol, not having access to the mutex means that it can't possibly set it to the state the CLR is looking for. More importantly if the CLR doesn't have access to the mutex, it can't use it to determine that security is off.

So our strategy is to simply create the mutex before anyone else on the machine, and ACL it down such that nobody is allowed access to it. We can pull this off in less than 20 lines of code:

int _tmain()
{
    // setup security attributes for the Mutex
    SECURITY_ATTRIBUTES sa;
    ZeroMemory(&sa, sizeof(sa));
    sa.nLength = sizeof(sa);
    sa.bInheritHandle = FALSE;

    // create a DACL to deny all access to the Everyone group
    TCHAR *securityDescriptor = _T("D:(D;OICI;GA;;;WD)");
    BOOL createdSecurity = ConvertStringSecurityDescriptorToSecurityDescriptor(
            securityDescriptor,
            SDDL_REVISION_1,
            &sa.lpSecurityDescriptor,
            NULL);
    if(!createdSecurity)
    {
        std::cout << "Could not create security descriptor." << std::endl;
        return 0;
    }

    // create the security off mutex with the handle
    HANDLE hMutex = CreateMutex(&sa, FALSE, _T("CLR_CASOFF_MUTEX"));
    if(hMutex == NULL)
    {
        std::cout << "Could not acquire mutex, security may already be off." << std::endl;
        return 0;
    }

    // wait to unlock
    std::cout << "Security is locked on.  Press any key to unlock." << std::endl;
    _getch();

    CloseHandle(hMutex);
    return 0;
}

First we setup a SECURITY_ATTRIBUTES structure that does not allow handles to inherit, and attach a DACL containing a single ACE which denies all access to the Everyone group. To create the DACL, we use the ConvertStringSecurityDescriptorToSecurityDescriptor function, which is available on Windows XP and later, so you'll need to use an XP machine to run this code, and define _WIN32_WINNT and WINVER to 0x0501 or higher before including windows.h and sddl.h

The string parameter to ConvertStringSecurityDescriptorToSecurityDescriptor looks a little daunting at first, but it's easy to break down:

D			Create a DACL
	(		Begin the first ACE
		D;	Deny
		OICI;	Object and container inherit
		GA;	GENERIC_ALL access
		;;	No object or inherit GUID
		WD;	Everyone group
	)		End ACE

After creating the security attributes, we attempt to create the mutex with them. If that fails, then it is possible the mutex already exists, perhaps because security is already off. Once we acquire the mutex, we just wait for the user to press any key to close it and exit.

When running this code, you'll notice that attempting to turn security off with CasPol will fail, and security will always be enforced by the CLR.

Now for the disclaimer. This code is really for demonstration purposes only, and is not a silver bullet against security being turned off.

For reasons we talked about last time, it does not affect the state of security on v1.x
There's an obvious race with CasPol ... whoever gets the mutex first wins
You cannot protect yourself against machine administrators. If a machine administrator wants to turn security off, they can attack this code in several ways. The most obvious being killing the process holding this mutex, or using one of several tools to just close the handle out from underneath it.

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.

Happy Birthday Channel 9

shawnfa — Thu, 07 Apr 2005 01:05:00 GMT

Channel 9 turns one year old today, and to celebrate they've been releasing quite a few interesting interviews. One in particular that really stands out is the four parter with Windows Kernel Architect Dave Probert. Dave gives an overview of Windows organization, design decisions, and lots of ways that Windows solves different problems. Along the way he gives various comparisons to how Unix operating systems approach the same issue, specifically referring back to his BSD roots. If you're interested at all in how Windows works under the cover, this is a nice introduction. People more familiar with how Windows works will find this mostly an overview, but I still found some of the comparisons and anecdotes Dave shared to be interesting.

Another good spot they've got up is an interview with Eric Lippert, who was actually the second interview to ever appear on Channel 9 (Bill Hill was the first). About 25% into this interview, Eric begins giving a 30,000 foot overview of CAS and then digs around through various other managed security issues, such as:

Strong Names vs Authenticode
Code access security vs role based security
Policy evaluation
How VSTO makes trust decisions
Assembly level declarative security
PermCalc

One of the more interesting points he mentions is how VSTO refines the default CLR security policy, for instance by saying "being granted FullTrust via the Zone and AllCode membership conditions, is not good enough."