Finding and Analyzing Permissions on Objects

One approach to testing permissions might be to log on with a user account that does not have permissions to the resource and verify whether access is denied. Although this method might seem reasonable, it is flawed and will cause you to miss permission problems. For example, say a product restricts a registry key so that only administrators have access to it. That registry key has a subkey that grants permission to the Everyone group . The bug might be dismissed because using the registry editor to attempt to navigate to the subkey as a nonadministrator causes an access denied error. Just because the user gets an access denied error when using the registry editor does not mean that enough testing has been completed to make sure that user really does not have access. The registry key that granted Everyone permission could be accessed if the exact path was used to specify the key, which can easily be done with just a little bit of code.

Before you can determine whether there are any permissions problems, you need to determine the permissions on your resources. Table 13-1 lists three tools you can use to make it easier to find permissions problems on resources.

Table 13-1: Common Tools Used to Find Permissions on Objects

	AccessEnum	Process Explorer	ObjSD
Files/directories	X	X	X
Network shares	X		X
Named pipes		X	X
Registry keys	X	X	X
Processes		X	X
Threads		X
Windows services			X
Mutexes /semaphores		X	X
Active Directory objects			X

You can use other tools to find permissions problems in addition to those listed in the table; however, this section discusses how to use the listed tools. The next section focuses on the details of finding common permissions problems.

Using the Windows Security Properties Dialog Box

In the Windows operating system, you can view the permissions on files, directories, or registry keys. Figure 13-2 shows an example of viewing the permissions on a registry key by right-clicking the key in Registry Editor and selecting Permissions. You can view the security properties on files and directories in a similar dialog box.

Figure 13-2: Permissions dialog box for a registry key

The Permissions dialog box shows that only the Administrators group and the System Account have permissions on the registry key. To see an advanced view of the permissions, as shown in Figure 13-3, click the Advanced button.

Figure 13-3: Advanced security settings for a registry key

To see the exact permissions select the permission entry and click Edit. This will show you the exact permissions on that object for that user or group, as shown in Figure 13-4. Notice in the figure that the Administrators group has only the Write DAC and Read Control permissions on this registry key.

Figure 13-4: Permissions entry for registry key

Although you can view the permissions for files, directories, and registry keys by using the security properties, you cannot solely rely on that information. Instead, you have to use other tools, especially if you want to check permissions problems with your application on objects other than files, directories, or registry keys.

Using AccessEnum

AccessEnum by Sysinternals ( http://www.sysinternals.com/utilities/accessenum.html ) makes it easy to enumerate the permissions on files, directories, network shares, and registry keys and their children to spot potential problems. The tool has two display settings:

• Objects that have less restrictive permissions than the parent object

• Objects that have permissions different from the parent object

Because this tool looks at all of the permissions from a particular parent down, it makes it easier to spot when the permission levels for an object have changed. Just specify a directory, network share, or registry to display who has access. Figure 13-5 shows the results of running AccessEnum against where programs generally are installed.

Figure 13-5: Results of running AccessEnum on the Program Files directory

Using Process Explorer

Although you might know some of the files and registry keys your application uses while running, the application probably uses a lot more than you think. Also, your application might use other securable objects that are harder to detect, such as mutexes and semaphores. Because the application might use these other types of securable objects, make sure you check the permissions on them as well.

Process Explorer by Sysinternals ( http://www.sysinternals.com/utilities/processexplorer.html ) enables you to see the securable objects that an application creates and uses, and it also displays the Security dialog box for the object. To use this tool, simply start Process Explorer and select the process that you want to observe. When you select a process, the handles the process currently has open are displayed in the lower pane of the tool, as shown in Figure 13-6. You can look at the security permissions on an object by right-clicking the entry and selecting Properties.

Figure 13-6: Viewing the handles of an application in Process Explorer

As you can see in Figure 13-6, which shows the handles of the application FwcAgent.exe in Process Explorer, there are several securable objects. If this were an application you were testing, you would need to check the permissions of each of the objects.

Using ObjSD

As mentioned earlier, an application can use securable objects other than files, directories, and registry keys. The command-line tool ObjSD, which you can find on this book s companion Web site, can be used to view the details of the security descriptor for a majority of securable objects. To use this tool, simply specify the object type and object name as command-line arguments. The following is the output of ObjSD on a directory called permissionExample .

 D:\>objsd.exe directory permissionExample Owner : BUILTIN\Administrators Group : SECBOOK\None ACE[ 0] : Allow : BUILTIN\Administrators : 0x1f01ff         : ( Del RCtl WDac WOwn Sync )         :()         :( List AddFile AddSubDir ReadEA WriteEA Traverse DeleteChild ReadAttr WriteAttr)         :( ContainerInherit ObjectInherit )          ACE[ 1] : Allow : \CREATOR OWNER : 0x1f01ff         :( Del RCtl WDac WOwn Sync )         :( )         :( List AddFile AddSubDir ReadEA WriteEA Traverse DeleteChild ReadAttr WriteAttr)         :( ContainerInherit InheritOnly ObjectInherit )          ACE[ 2] : Allow : BUILTIN\Users : 0x100006         : (Sync)         : ()         : ( AddFile AddSubDir )         : ( ContainerInherit ) 

The output reveals the following information about the security descriptor:

• The creator/owner of the directory was in the Administrators group.

• The DACL contains three ACEs.

• The order of the ACEs is shown.

• Each ACE shows which permissions are granted.

The first line shows the ACE type (Allow or Deny) for the specified user or group. The second, third, and fourth lines are the standard rights, generic rights, and object-specific rights, respectively. The last line shows the inheritance settings. Using the output shown, can you tell what the last ACE does? It grants all Users access to use the object for synchronization and to create directories and files below it, and it causes the children to inherit the permissions from the container.

Using AppVerifier

Microsoft has a tool called AppVerifier that can be used to test an application for several different issues. Even though the tool is primarily used to test for compatibility issues with the Windows operating system, it can also detect some common security issues, especially access control issues that an application might create. Refer to http://msdn.microsoft.com/library/en-us /dnappcom/html/AppVerifier.asp for more details on this tool.