Mark's Sysinternals Blog

I’m proud to announce that a major step forward in the legal phase of Sony's rootkit: Scott Kamber and Sony have filed a proposed settlement for the national class-action suit brought by Scott. While I didn’t participate directly in the negotiations, I’m serving as an expert for Scott and provided input on the terms, which I think are a significant victory for the consumer.

I won’t recount the specifics of the agreement, which incidentally isn’t final until approved by the Southern US District Court of NY, because other articles have already summarized them. However, the basics include consumer incentives for returning their DRM’d CDs in the the form of money and/or free albums (from a choice of sources, including iTunes!) and independent oversight for the next two years over Sony’s DRM development and EULAs. In addition, Sony waives most of the terms of the existing XCP and MediaMax EULAs and allows customers that experienced computer problems as a result of the software to file independent claims outside the settlement.

Reaction to the news has generally been positive, but there are some that believe that Sony has been dealt little more than a slap on the wrist. I had no reservations giving the settlement my approval and think that this specific circumstance has had a best-case outcome for those affected.

I certainly don’t think that this should be the end of the general story, though. While Sony is now bound, at least in the short term, to constraints that protect the public from repeats, other companies still have great leeway in their approach to DRM. I’ve made it a theme of my posts on this topic that the government needs to formalize in law some of the core guidelines of the Sony settlement. Fundamentally, users need to have enough plain-English information presented to them during a software installation, DRM-protected or otherwise, that helps them make an informed decision when they consider accepting a vendor’s terms and the software's impact on their system. It should also be law that vendors must include a local uninstall functionality. Until changes are made we’re all at risk of losing control of our computers to aggressive DRM tactics.

Active Directory Group Policy settings are widely used to secure Windows systems because they can be customized to target and deploy to specific computers and users in an Active Directory-based network. In a previous blog post I warned that one of the risks of having end-users with local administrative privilege is that they can override group policy settings at will and I promoted limited-user accounts as the secure alternative. However, Windows administrators should be aware that if a user, even one running with a limited account, can execute just one program of their choice that they also can circumvent many group policy settings, including ones aimed specifically at tightening security such as Software Restriction Policies and Internet Explorer Zones.

The vulnerability within many group policy settings is that the applications at which they are directed enforce the settings. For example, Explorer limits execution of certain applications if Group Policy dictates and Internet Explorer implements Zone security. The Windows architecture sets security permissions on a process that allows the owner of the process full control over the process, which you can verify in the Permissions dialog that you access from the properties dialog of a process in Process Explorer:



That means that users can alter the code or data of their own processes, including Explorer and Internet Explorer, and by manipulating the code or data related to Group Policy enforcement they can bypass Group Policy settings.

Software Restriction Policies (SRP) are another example of Group Policy settings that can be subverted by limited users if you allow them to run an arbitrary executable – in other words, if you don’t apply SRP correctly by using it to define the executables users can run (whitelisting) instead of simply singling out executables that you don’t want them to run (blacklisting). When a user launches a process it’s the parent process that checks SRP to see if the execution of the child should be allowed or blocked, allowing the owner of the parent process to manipulate the process into bypassing or negating SRP processing. There are many ways of accomplishing that, including writing a program that reaches into the parent’s address space and changes the Registry path strings that refer to SRP storage or overwriting the code that reads SRP Registry settings.

I’ve written a simple application, Gpdisable, that demonstrates the ease with which SRP can be disabled by even a limited user. The program uses the DLL injection techniques described by Jeff Richter in Programming Applications for Microsoft Windows (Microsoft Press) to load a DLL into all the processes on the system to which the user running it has access. The DLL places a hook on the NtQueryValueKey API so that it intercepts any calls of the API made by those processes or the DLLs they’ve loaded. The Windows SRP code uses NtQueryValueKey to query the Registry value HKLM\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers\TransparentEnabled, which if present and non-zero indicates that SRP is turned on. Here’s a Regmon trace of Cmd.exe, the Command Prompt, reading the value in response to an attempted execution of Notepad.exe, which I’ve disallowed using SRP:



Users don’t have permission to modify keys under HKLM, including the SRP settings, but Gpdisable fools the SRP code by returning an error value, STATUS_OBJECT_NAME_NOT_FOUND, whenever it sees a value named “TransparentEnabled” passed to NtQueryValueKey:



This screenshot shows the “The system cannot execute the specified program.” error SRP reports in the failed attempt to run Notepad.exe in a limited user account followed by execution of Gpdisable and subsequent successful execution of Notepad.exe:



Note that existing processes that have already launched children, such as Explorer and Command Prompt, cache the TransparentEnabled value and so will continue to enforce SRP. You could almost as easily override that by modifying a program like Gpdisable to reach into them and change their cached values.

The Regmon trace of the second Notepad execution looks similar to the first with the major exception that the query of TransparentEnabled is missing: Gpdisable intercepted it in user-mode and so the call never progressed into the kernel:



What other Group Policy settings are susceptible to this type of attack? System-wide security settings are enforced by core operating system components not accessible to limited users, but most of the settings in the Windows Components area of the Group Policy editor’s Administrative Templates node are ineffective in environments where end-users can run arbitrary applications such as Gpdisable:



Notably, Internet Explorer configuration, including Zones, fall into this area, as do Explorer, Media Player, and Messenger settings. The bottom lines is that full control of an end-user environment is possible only with strict lock-down of the programs users run, something that you can accomplish by using SRP in white-list mode, for example. It's also important to note that the ability of limited users to override these settings is not due to a bug in Windows, but rather enabled by design decisions made by the Microsoft Group Policy team.