MSDN Magazine - November 2008 - (Page 70)

user attacks. Then administrator, system (system does not really need it), and CO are given full control = File All. For the Shared Read scenario, an authenticated user is granted List, AddFile, AddSubDir, ReadEA, Traverse, ReadAttr, RCtl, and Sync due to the restriction of this grant to CI, and thus to directories, and is separately granted Generic Read to all files. For the Collaborative scenario, an authenticated user is granted Delete, Generic Read, and Generic Write on files and directories. Managing the Registry and Its Permissions Windows stores much of its state information in the Windows Registry. Registry data stores are known as Hives, where data is stored in keys and subkeys, which are both viewed as containers (subkeys are not viewed as objects). User-specific data is stored in the appropriate user section of Hive Key Users (HKEY_USERS). As one would expect, much of this data is writeable by the user. In any session, HKey_Current_User (HKCU) points to the appropriate section of HKEY_USERS. System and machine information is stored in the HKEY_LOCAL_MACHINE (HKLM) hive. Included in HKLM is information for all the various system services, most of which now run with limited permissions under either the various Local Service or Network Service groups. Services and applications can store state information in their registry keys. This information should notepad.exe. The default ACL over C:\windows does not allow an attacker to modify the executable. If the attacker can rewrite the link from the Notepad icon to its executable, the attacker can cause a different file, say C:\tools\load_rootkit.exe, to load. This could load a rootkit and then load Notepad so that the user would not be aware of the compromise. If the attacker can drive the link through the registry, the protective ACLs on the file system are immaterial. You are concerned with attacks from limited system services against other system services as well. In Windows Vista and Windows Server 2008, services are separated into groups by the privileges they need. The defense-indepth protections offered by this service isolation require configuration of the service permissions so that services cannot tamper with one another, particularly across service groups. Just as we are concerned with preventing users from adding or linking to malicious executables, we must also prevent services from having the ability to change their permissions and capabilities. The ChangeConf privilege on services must be restricted to administrator, system, or Trusted Installer since this privilege allows the possessor to change the permissions on the service. Wrap-Up You must not grant services the ability to change their permissions and capabilities. be stored in subkeys, either in the service key or in a key under the service key. The service key must not be ACL’d to enable the service to have SetKey over its own service key (or the WDac or WOwn, which would enable such an attack), as this allows the service to point to a different executable. Such an error introduces a potential EoP against the service host, as the Service Control Manager will load the executable that is pointed to when the system loads. The general guidance for DACLs for HKLM is that they must not enable users to write or modify this data or the associated ACLs and ownership. As with the guidance on setting file system DACLs in system areas, exceptions occur for error logging where an app or a service running under a user or limited context needs to record error information. The guidance for such situations is similar to equivalent issues in the file system—create separate keys for such information and ACL them appropriately. Thus the sensitive information can be ACL’d to trusted subjects (administrator, system, and so on) and the logging data can be writeable, as needed. The situation you are trying to avoid is a user modifying trusted parameters (such as turning the antivirus or anti-malware service off) or tampering with a tool that users or administrators use. Let’s assume that when Notepad is invoked it loads C:\windows\ 70 msdn magazine Windows provides a very rich set of permission controls that can be used to permit operations, block operations, and provide defense-in-depth against new threats. Unavoidably associated with this rich ability to control access is the issue of complexity. Following a few general guidelines will help you avoid problems. For instance, the system defaults are reasonable compromises. You should use them. If you are installing an application outside of program files, use the program files ACLs. In some cases you may want to tighten defaults a little bit, such as the default grants to users on drives; but remember that if you indeed do this, you must be prepared to look for and deal with potential application compatibility issues. The most important guideline is that administrators or system accounts must not execute code or follow pointers to code that a user can write or modify. Almost as important is that users not execute code or follow pointers to code that another user can write or modify. These guidelines drive all of the security issues discussed here. If any changes you make follow these guidelines, you have avoided the most serious security issues. For more information about access control components, see msdn.microsoft.com/library/aa374862. Information about the ace_string access mask components can be found at msdn.microsoft.com/library/ aa492637 and includes pointers to specific rights for files, directories, registry keys, and shared sections. Additional information about restricted SIDs can be found at msdn.microsoft.com/library/aa379316.  John R. MicheneR is senior security program manager for Microsoft. He joined Windows Security at Microsoft almost 5 years ago. John has more than 20 years of experience in system security and has done three security startups. He is the cryptography and permissions expert for the Windows Software Assurance team. You can reach him at jmichene@microsoft.com. File and Registry Permissions http://msdn.microsoft.com/library/aa374862 http://msdn.microsoft.com/library/aa492637 http://msdn.microsoft.com/library/aa492637 http://msdn.microsoft.com/library/aa379316

Table of Contents Feed for the Digital Edition of MSDN Magazine - November 2008

Contents MSDN Magazine - November 2008 Toolbox CLR Inside Out Data Points Cutting Edge Security Briefs Test Your Security IQ Agile SDL Access Control Utility Spotlight RIA Test Run Wicked Code Foundations Team System End Bracket

MSDN Magazine - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.