Mandatory Profiles – Insecure by Default?

This article is part of Helge’s Profile Toolkit, a set of posts explaining the knowledge and tools required to tame Windows user profiles.

Mandatory profiles are generally considered fast and secure because they usually are small in size and cannot be modified by the user. While that is true – mandatory profiles stay pristine indefinitely – there is more to security than read-only access.

Mandatory profiles (MP) are a variant of roaming profiles: a master copy on a file server is copied to the RDS session host during logon. The resulting local copy is secured with file system ACLs that grant full access to the user, but no one else (plus administrators and SYSTEM). All is safe and secure – except in the case of mandatory profiles.

A user profile consists not only of file system data, but also of a registry hive (stored in the file NTUSER.MAN) that is mounted to HKU\<SID> and accessible from within a session via the well-known name HKCU. In contrast to the file system, registry permissions are not changed during logon because that is not necessary – at least with roaming profiles where the master copy of each hive already has the correct permissions.

Not so with mandatory profiles. As per the KB article How to customize default user profiles in Windows 7 (and older similar articles) the creation of a mandatory profile involves changing registry permissions on the master copy to full access for “Everyone”. Since many users are logged on simultaneously to an RDS session host, each server’s registry is comprised of many users’ hives that are read- and writeable by anyone, not just the owner of the individual user profile as it should be.

So on a RDS session host where mandatory profiles are used, a user can simply open Regedit, navigate to HKU\<Some other user’s SID> and read/write at will.

Consequences

Users being able to read/write somebody else’s HKCU hive poses a potentially grave security problem. At least two types of attacks can be envisioned: eavesdropping and damaging. Here are some simple examples:

• Many applications store a list of most recently used (MRU) files in HKCU (e.g. Microsoft Word: HKCU\Software\Microsoft\Office\12.0\Word\File MRU). By reading such lists, attackers can gain information on which documents another user is editing.
• Applications and the operating system itself need and expect write access to HKCUy. Since a user always has write access to HKCU, programs do not handle the absence of such permissions well. By changing permissions on another user’s hive an attacker could effectively break the other guy’s session.

How to Fix

The following workarounds can help fix this security vulnerability:

1. Do not use mandatory profiles on multi-user systems. On single-user systems make sure that remote registry editing is limited to administrators.
2. Block access to the registry via software restriction policies. This includes, but is not limited to, Regedit.exe, Cmd.exe, Reg.exe, scripts and batch files, custom (downloaded) tools. In essence, in order to fix this problem exclusive white-listing is required.
3. Re-ACL each registry hive after it is loaded and replace “Everyone” with the current user.

About This Article

I originally wrote this text for the Windows Server 2008 R2 Remote Desktop Services Resource Kit by Christa Anderson and Kristin L. Griffin.