The Registry

The registry is an integral part of Windows operating systems. It provides a centralized database containing configuration information about software installed on the system and the system itself. Applications often access the registry, and the manner in which they do so is quite important for security reasons because the information in there can direct how the program operates. Information in the registry can be stored in several formats and is used for controlling many aspect of a program's behavior. Applications might store pathnames to more detailed configuration files or helper DLLs, integer values that determine the level of processing an application performs on a file, and so forth. You need to be able to examine each access to the registry in an application to determine whether it's done securely; if it isn't, you must evaluate the level of danger that the application is exposed to if someone takes advantage of an insecure registry access.

The registry is organized in a large tree structure. Each top node is called a key, each nonleaf node below a top node is a subkey, and each leaf node is a value. Several predefined keys exist on every system. Table 11-12 summarizes them, based on information in the MSDN.

Table 11-12. Predefined Registry Keys

Name	Purpose
HKEY_CLASSES_ROOT	Used for storing file type information and their associated properties. It is an alias to a branch in HKEY_LOCAL_MACHINE.
HKEY_CURRENT_CONFIG	Used for system hardware configuration information. It is an alias to a branch in HKEY_LOCAL_MACHINE.
HKEY_CURRENT_USER	Used to store preferences for the current user. Each user has his or her own set of preferences, and retrieving values from this key provides access to user preferences, depending on the identity of the process accessing the key. It is an alias to a branch in HKEY_USERS.
HKEY_LOCAL_MACHINE	Used to store information about hardware, systemwide configuration parameters (such as network configuration), and systemwide software configuration details.
HKEY_USERS	Contains default user profile information to be used for new users and profile information for all the users on the system.

Key Permissions

As mentioned already, keys are securable objects, so they have a set of access rights used to restrict who can read and write to keys and constituent vales. Table 11-13 summarizes these access rights, based on information in the MSDN.

Table 11-13. Key Access Rights

Access Right	Meaning
KEY_CREATE_LINK	Reserved.
KEY_CREATE_SUB_KEY	Allows users to create a subkey of a registry key.
KEY_ENUMERATE_SUB_KEYS	Allows users to enumerate all subkeys of a registry key.
KEY_EXECUTE	Same as KEY_READ.
KEY_NOTIFY	Allows a user to receive a notification when a change is made to the given registry key or one of its subkeys.
KEY_QUERY_VALUE	Allows users to query values of a registry key.
KEY_READ	Equivalent to combining STANDARD_RIGHTS_READ, KEY_QUERY_VALUE, KEY_ENUMERATE_SUB_KEYS, and KEY_NOTIFY.
KEY_SET_VALUE	Allows users to create, delete, or modify values in a key.
KEY_WOW64_32KEY	Allows a 64-bit application to access the 32-bit registry view of the key.
KEY_WOW64_64KEY	Allows a 64-bit application to access the 32-bit registry view of the key.
KEY_WRITE	Equivalent to combining STANDARD_RIGHTS_WRITE, KEY_SET_VALUE, and KEY_CREATE_SUB_KEY.
KEY_ACCESS_ALL	Combines all values listed in this table.

The permissions applied to keys created by applications are quite critical because the capability to manipulate them can result in severe modification of an application's behavior. The exact effects of altering registry keys is very application specific. In the worst case, however, unchecked registry manipulation could allow an attacker to manipulate the most critical elements of a Windows system.

Another important point is that registry keys can be secured but registry values can't. The values are simply in the security scope of the keys, so any attempt to implement a permission boundary must be applied to keys, not values.

Key and Value Squatting

As with all other named objects, keys could potentially be created before an application creates them. This could allow attackers to supply arbitrary values to the key, regardless of permissions the application attempts to enforce. Key squatting is far less likely than other name squatting for two main reasons:

• Applications often create keys and values only once, when the application is installed. To create a key before an application does, you might have to create it before the application is actually installed, which drastically limits exploitability.

• The default permissions on registry hives are quite strict, allowing only administrative users to write to the portions under the local machine hive. Therefore, there's far less chance that malicious users can write to sensitive keys or values.

Despite these reasons, key squatting might still be an issue. Services can store session-related information in the registry, allowing applications to potentially squat on key and value pairs. Client applications might also perform similar operations that leave them vulnerable to client-side registry squatting attacks. Here's the API for creating and opening registry keys:

LONG RegCreateKeyEx(HKEY hKey, LPCSTR lpSubKey, DWORD Reserved,     LPTSTR lpClass, DWORD dwOptions, REGSAM samDesired,     LPSECURITY_ATTRIBUTES lpSecurityAttributes, PHKEY phkResult,     LPDWORD lpdwDisposition)

The RegCreateKeyEx() function is responsible for creating a new key or opening an existing key. The first parameter is a handle to an existing key or one of the predefined keys discussed earlier. The second parameter is the subkey to create or open. All the remaining parameters provide information about the subkey, such as what type of data is stored in the key, associated security permissions, and so forth.

If the key already exists, all parameters pertaining to the type of key and the key access permissions are ignored. When looking for key-squatting issues, the last parameter, lpdwDisposition, is important. This value is filled in by RegCreateKeyEx() and can contain REG_CREATED_NEW_KEY to indicate it created the key successfully or REG_OPENED_EXISTING_KEY. Therefore, an application is immune to key squatting if it checks this value, as shown in this example:

BOOL CreateNewKey(HKEY hKey, LPCSTR lpSubKey, HKEY hNewKey) {     DWORD dwDisp;     if(RegCreateKeyEx(hKey, lpSubKey, NULL, NULL,         REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS,         NULL, &hNewKey, &dwDisp) != ERROR_SUCCESS)         return FALSE;     if(dwDisp != REG_CREATED_NEW_KEY)         return FALSE;     return TRUE; }

However, if an application fails to check the lpdwDisposition value and is writing to a registry location accessible to malicious users, the potential for key squatting exists. The following example is a slightly modified version of the CreateNewKey() function that's now vulnerable to key squatting:

BOOL CreateNewKey(HKEY hKey, LPCSTR lpSubKey, HKEY hNewKey) {     if(RegCreateKeyEx(hKey, lpSubKey, NULL, NULL,         REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS,         NULL, &hNewKey, NULL) != ERROR_SUCCESS)         return FALSE;     return TRUE; }

Notice that a NULL value is supplied as the disposition argument to RegCreateKeyEx(). Therefore, there is no way of knowing whether a new key is a created key or an existing one is opened. This failure to check for the key's creation state leaves this code vulnerable to key squatting attacks.