Over a relatively short period of time, the attitude toward software security haschanged dramatically, both from the developer perspective, as well as from the userperspective. Years ago, computers were mostly disconnected devices, and offlinemedia, mostly floppy disks, was the main source of computer security problems. Thebig problem at that time was represented by viruses. Today, almost every computersecurity problem is remotely exploitable because of the high connectivity rate.Older operating systems, such as Windows 95, provided no support for securingobjects stored on the local computer. The advent of the Windows NT code base in consumermarkets made a secure C2-compliant kernel available to consumers. Today, theconsumer versions of the Windows operation system—namely Windows XP Home andWindows Vista Home—control the access to each object, and, as such, the chanceincreases for encountering an access denied failure. Another push comes from the securitycommunity to always run a process with the least privileged user. In this case, the hostcomputer is isolated from security vulnerabilities that might exist in the applications.How feasible is it to run the application as a nonadministrator? Perhaps it is possible fora few applications, designed with security in mind, while the majority of them will still tryto access a registry location or a file system location reserved only to administrators.Hopefully, object security will become a first-class development pillar. This topicprovides the information required to start the journey toward successful understandingand fixing of software security problems. This topic focuses primarily onsteps executed when a legal operation completes with success of failure and doesn’tdescribe unexpected behavior of code because of code defects (buffer overflow, integeroverflow, buffer overrun), currently exploited by viruses, as it is covered very wellin several reference books. In this topic, we explore the following:■ The basics of Windows security and how Windows Security actually works. Wesummarize the essential information required to understand security-relatedproblems.■ How to inspect various security elements using the debugger extensions. This sectionintroduces several extension commands essential to debugging securityaspects.■ How to combine the techniques and information presented so far in the bookto resolve problems caused by unexpected security restrictions.
Any Windows securable object, which can be represented by a handle to it, has securityinformation attached to it, and it is protected using standard Windows securitymechanisms. The Windows security model uses three security concepts:■ The discretionary access control list (DACL): Describes what principal can usethe object and how■ The identity of the user: Also known as principal■ The Security Reference Monitor (SRM): Uses the information available torestrict the access to the object protected by itDACLs associated with Windows securable objects are managed by the object creatoritself. The DACL is a component within another structure known as the securitydescriptor, which is a small piece of information stored along with the object in thesecured store. The security descriptor is retrieved from the secured store, and it isused every time the object is accessed by a new principal. For example, the files securitydescriptors are stored in the NTFS file system, the registry keys security descriptorsare stored in the registry hives, whereas the kernel objects have the securitydescriptors stored in the kernel address space.The Windows SRM runs in the kernel address space, isolated from the user modecode. Most securable objects are created and managed by kernel components thatuse the address separation to protect the associated security descriptor from the usermode components. Because user mode components cannot use the kernel for implementingtheir own secure object brokers, several components in Windows implementcustom security models using ideas similar to the Windows security mechanisms.A custom object broker must enforce the mechanism for accessing its object. Inother words, when designing a securable objects broker, you must ensure that thisobject cannot be accessed by using any other mechanism. In those cases, the objectbroker takes the SRM role and manages the object security descriptors in its proprietaryways. To ensure functional consistency with the rest of the operating system anduse the same user interface controls in security settings, the object broker will mostlikely use the same data structures as Windows SRM.The other essential component in access control is the security principal, createdand certified by the operating system. The security principal is stored in an accesstoken that aggregates the list of group security principals having the principal as amember, the list of special privileges granted by the operating system, plus otherinformation used by the various components in the system.The access to an object is represented by a collection of bits, each bit representinga right (specific to the object’s nature) that can be granted or denied to a principal.
The next section describes all the security structures relevant to debugging Windowsapplications, and it presents various methods for inspecting them. Readers familiar withthose concepts can skip this section. All examples use three new extension commands:!sd, !token, and !sid, available in the default extension loaded by debuggers. Thisuses the 07sample.exe with the source code and binary located in the followingfolders:Source code: C:\AWD\popBinary: C:\AWDBIN\WinXP.x86.chk\07sample.exeBecause the security errors are often encountered in distributed applications.consisting of a client application 08cli.exe, a library, 08comps.dll that contains theproxy-stub code, and a server application 08comsrv.exe. The 08comsrv.exe must beregistered using the 08comsrv.exe /RegServer command line, and 08comps.dll mustbe registered using the regsvr32 08comps.dll command line. The source code and thebinary files are located in the following folders:Source code: C:\AWD\popBinaries: C:\AWDBIN\WinXP.x86.chk\08cli.exe, 08comps.dll, and08comsrv.exe
Any Windows securable object, which can be represented by a handle to it, has securityinformation attached to it, and it is protected using standard Windows securitymechanisms. The Windows security model uses three security concepts:■ The discretionary access control list (DACL): Describes what principal can usethe object and how■ The identity of the user: Also known as principal■ The Security Reference Monitor (SRM): Uses the information available torestrict the access to the object protected by itDACLs associated with Windows securable objects are managed by the object creatoritself. The DACL is a component within another structure known as the securitydescriptor, which is a small piece of information stored along with the object in thesecured store. The security descriptor is retrieved from the secured store, and it isused every time the object is accessed by a new principal. For example, the files securitydescriptors are stored in the NTFS file system, the registry keys security descriptorsare stored in the registry hives, whereas the kernel objects have the securitydescriptors stored in the kernel address space.The Windows SRM runs in the kernel address space, isolated from the user modecode. Most securable objects are created and managed by kernel components thatuse the address separation to protect the associated security descriptor from the usermode components. Because user mode components cannot use the kernel for implementingtheir own secure object brokers, several components in Windows implementcustom security models using ideas similar to the Windows security mechanisms.A custom object broker must enforce the mechanism for accessing its object. Inother words, when designing a securable objects broker, you must ensure that thisobject cannot be accessed by using any other mechanism. In those cases, the objectbroker takes the SRM role and manages the object security descriptors in its proprietaryways. To ensure functional consistency with the rest of the operating system anduse the same user interface controls in security settings, the object broker will mostlikely use the same data structures as Windows SRM.The other essential component in access control is the security principal, createdand certified by the operating system. The security principal is stored in an accesstoken that aggregates the list of group security principals having the principal as amember, the list of special privileges granted by the operating system, plus otherinformation used by the various components in the system.The access to an object is represented by a collection of bits, each bit representinga right (specific to the object’s nature) that can be granted or denied to a principal.
The next section describes all the security structures relevant to debugging Windowsapplications, and it presents various methods for inspecting them. Readers familiar withthose concepts can skip this section. All examples use three new extension commands:!sd, !token, and !sid, available in the default extension loaded by debuggers. Thisuses the 07sample.exe with the source code and binary located in the followingfolders:Source code: C:\AWD\popBinary: C:\AWDBIN\WinXP.x86.chk\07sample.exeBecause the security errors are often encountered in distributed applications.consisting of a client application 08cli.exe, a library, 08comps.dll that contains theproxy-stub code, and a server application 08comsrv.exe. The 08comsrv.exe must beregistered using the 08comsrv.exe /RegServer command line, and 08comps.dll mustbe registered using the regsvr32 08comps.dll command line. The source code and thebinary files are located in the following folders:Source code: C:\AWD\popBinaries: C:\AWDBIN\WinXP.x86.chk\08cli.exe, 08comps.dll, and08comsrv.exe
