Foiling Malware with Software Restriction Policies

Published on Monday 17th September, 2007 (AEST)

Around 18 months ago I decided to try an experiment. I was frustrated by spyware, and the effort required maintaining the hygiene of systems belonging to clients, friends, and family. It seemed as though spyware scanners were struggling to keep up and I hated the idea of having multiple malware scanners running on my systems. So, on my laptop, I decided to take a different approach.

No, I didn't load Linux or move to a Mac. Instead, I set up Software Restriction Policies. Then, to make it interesting, I dispensed with virus and malware scanners. (I’m not suggesting readers do likewise). My purpose was twofold: to gauge the effectiveness of the approach, and to determine its limitations. Over the past 18 months, I’ve been surprised at how few configuration problems I’ve had. And I haven’t suffered at the hands of spyware.

Software restriction policies were introduced with Windows XP, but their use has been largely limited to corporate environments and education facilities. As the name implies, Software Restriction Policies regulate which applications may run on particular machines, or for particular users. Accordingly, they are commonly configured to prevent an organisation’s users from installing new applications, or accessing applications to which they're not allowed.

In this article I discuss their implementation purely for the purpose of foiling malicious software. A working knowledge of Group Policy is assumed. Please note that due to the nature of software restriction policies, thorough testing is required prior to deployment on your production machines.

The Approach

This approach uses a white-list technique, only allowing trusted software to run. This differs from the black-list approach of virus scanners, whereby any software may run so long as it isn’t recognised as malicious. The success of a white-list approach therefore hinges on your ability to determine which software to trust, while the black-list approach relies on a frequently updated list of unwelcome code. There is no reason you can’t use both.

By specifying the location of trusted software, and ensuring that user accounts don’t have write or modify access to those locations, you have complete control over which software may run. For example, regular user accounts do not have write or modify access to the Windows or Program Files folders by default, so by restricting users to only applications in these folders, distrusted code is unable to run. I might mention that email attachments are run from the user profile, not the Program Files folder.

You have the choice of applying the policies to all users, or just non-administrators. Additional testing would be required if you were to apply the policies to administrator accounts, and you would need to disable the policies in order to install new software. If administrator accounts are exempt from the policies, they should only be used when absolutely necessary, and not for everyday use. Besides, as Aaron Margosis suggests, using a limited account should actually offer more protection than a virus scanner.

Configuration

Software Restriction Policies are configured through a Group Policy Object, either in Active Directory or on a local computer. If you are applying the policies through Active Directory, create a new GPO for the Software Restriction Policies, rather than editing an existing policy. This allows the policy to be disabled quickly if necessary. The settings are contained in the Windows Settings -> Security Settings -> Software Restriction Policies node of either the Computer Configuration or the User Configuration. You would generally configure the policies in the Computer Configuration, unless you were seeking to limit their application to specific users.

The Enforcement settings allow you specify whether the policies apply to DLLs as well as executables, and whether they apply to administrators. Although applying the policies to DLLs adds a little more protection, it can have an impact on performance. Excluding DLLs simply means that the DLLs are treated in the same way as the application that calls them, rather than being treated as unique software.

In Designated File Types, you can specify which types of files are regulated. You should confirm that ActiveX controls (.ocx) are listed, and removed links (.lnk) from the list.

In the Security Levels node you specify what the default rule is. By specifying Disallowed, you ensure that users cannot run any applications unless another rule permits it. This is the most thorough method for preventing malware, but it also requires thorough testing of your applications.

Finally, the Additional Rules settings allow you to specify which software may run. For each additional rule, you may specify whether software that matches the rule is Unrestricted or Disallowed. Vista and Longhorn also provide a Basic User option, which forces the software to run with limited-user permissions. Four rules are automatically created when you specify the default rule as disallowed. These rules ensure that Windows will run correctly, and give access to software in the program files directory. For many environments, this will be sufficient. Some software, particularly legacy applications, may require additional rules.

There are four types of rules: path rules, hash rules, certificate rules, and zone rules. By far the most useful are path and certificate rules. Path rules specify the path of an application, and can point to a registry value where an application path is stored. This is useful when the software may be installed in different locations on different computers.

To enable trusted ActiveX controls, you can use certificate rules. When installing an ActiveX control (while logged in as an administrator), you are asked if you want to install <software-name> published by <vendor-name>. Click on the name of the vendor (Microsoft, Adobe, etc) to view the certificate, then click the Details tab. Click on Copy to File... to step through the Certificate Export Wizard. Save the certificate in DER encoded binary X.509 (.CER) format on your hard drive. Finally, create a certificate rule in the group policy object, pointing to the certificate you exported, and set the security level to Unrestricted. User accounts will now have access to ActiveX controls that are installed, as set by your certificate rules.

Figure 1: Additional rules.

To allow certificate rules for executables, you may need to enable the setting System settings: Use Certificate Rules on Windows Executables in Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options section of your GPO.

Tip: Software Restriction Policies do not apply when the computer is running in safe mode. If you mess up your policy and lock yourself out, restart the computer in safe mode and login as administrator. You can then correct the issue.

For more details on configuring Software Restriction Policies, see the documentation on Technet.

Limitations

Even when running as a limited user with software restriction policies configured, there is still some risk in not having a virus scanner or other malware protection software installed. Specifically, trusted software that you install may in fact be malicious, or be infected with malicious code. However, by being judicious about which applications are installed, this risk may be diminished.

Software Restriction Policies are not included in Security Templates. As such, there is no simple method for deploying policies onto multiple machines in a non-Active Directory environment.

Software restriction policies are not available on operating systems released prior to Windows XP, or on the "Home" editions of XP and Vista.

This topic is discussed further in:

When Administrators aren't Trusted (28th Sep, 2007)

Curious behaviour in Software Restriction Policies

Virus Scanners - Prevention or Detection? (31st Oct, 2007)

The purpose of virus scanners in a white-list environment

Save to del.icio.us Digg this Submit to StumbleUpon