by Chris Wysopal, Lucas Nelson, et al.
This article is an excerpt from the book, "The Art of Software Security Testing," and focuses on the approach and techniques used to test the security of local applications. It begins by describing local resources and interprocess communication, which make up a local application’s attack surface. After describing how to enumerate the local resources an application depends on, the text then describes methods of testing several of those types of resources. It also describes how to test ActiveX objects, command-line programs, and applications’ use of local files and shared memory.
Local Resources and Interprocess Communication
Modern operating systems offer a number of facilities for data input, sharing, and storage. An application’s threat model must identify the local system resources that the application depends on and identify which of those may be controlled or affected by an attacker. We refer to this as the application’s local attack surface. For example, every application depends on the executable file and shared libraries that make up the application’s code. These files are typically protected by the operating system against modification by unprivileged users through file system permissions and access control lists (ACLs). However, if the application includes a directory that is writable by unprivileged users in its shared library load path, a local attack may be possible by creating a rogue shared library in this directory.
If the application depends on shared libraries that are loaded from outside the operating system’s shared library directories, or if it uses the API functions LoadLibrary(Win32) or dlopen(UNIX), these directories and how the application loads libraries or plug-ins must be considered part of the application’s local attack surface and must be tested. For example, the SAP DB database had a local privilege escalation vulnerability through this mechanism. The database installed a Windows service configured to run as SYSTEM, launched from a directory that was writable by any user on the system. If a user placed a shared library named NETAPI32.DLL in this directory, it would be loaded into the privileged service, resulting in a privilege escalation vulnerability.
In the Internet age of rapid communication, files are seamlessly copied from Web servers or file servers to local files and are opened by local applications. This movement makes file parsing vulnerabilities much more serious when files that may have been corrupted by a malicious user are opened in applications not hardened against this sort of attack. For example, consider an application that processes files provided by remote users such as a Web browser or e-mail client. If the application in question opens potentially corrupted files provided by untrusted users, errors in the processing of these files may result in an application crash or, even worse, code execution. In this case, the application code that processes these files forms an important part of the application’s local attack surface area and must be closely examined for vulnerabilities and tested using a technique such as file format fuzzing, as described later.
Windows NT Objects
A local application may also use a number of other resources, including command-line arguments, environment variables, or interprocess communication objects such as shared memory or semaphores. Windows NT-based operating systems, for example, support a number of potentially shareable local resources that are often called objects. These objects include files, devices, network sockets, shared memory segments, Registry keys, processes, threads, and more. Each of these objects may have a name so that other processes can refer to it and an ACL defining the object’s access permissions to other users of the system.
The NT Kernel Object Manager maintains a file system-like namespace for these objects. A process may open an object by passing one of these names to a system function such as CreateFile. You can browse this namespace by making calls to the Windows NT Native API functions in NTDLL or by using a browsing utility such as WinObj. WinObjis a freeware utility from Sysinternals Freeware. It lists the NT Object Manager namespace and allows the user to browse the name- space and query object attributes and permissions. Continued as a PDF...
The complete text is available as a PDF (1.6Mbytes). The text reads as a stand-alone article and was taken from Chapter 11 of the book, The Art of Software Security Testing: Identifying Software Security Flaws, by Chris Wysopal, Lucas Nelson, Dino Dai Zovi, and Elfriede Dustin (with a foreword by Dan Geer). Published in 2007 by Addison Wesley and Symantec Press.
This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.