USENIX Association Proceedings of the 12th USENIX Security Symposium Washington, D.C., USA August 4–8, 2003 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2003 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. Preventing Privilege Escalation Niels Provos Markus Friedl Peter Honeyman CITI, University of Michigan GeNUA CITI, University of Michigan Abstract gain extra privilege after successful authentication lim- its the degree of escalation because the user is already Many operating system services require special priv- authorized to hold some privilege. On the other hand, ilege to execute their tasks. A programming error in a a remote adversary gaining superuser privilege with no privileged service opens the door to system compromise authentication presents a greater degree of escalation. in the form of unauthorized acquisition of privileges. In For services that are part of the critical Internet the worst case, a remote attacker may obtain superuser infrastructure is it particularly important to protect privileges. In this paper, we discuss the methodology against programming errors. Sometimes these services and design of privilege separation, a generic approach need to retain special privilege throughout their life- that lets parts of an application run with different levels time. For example, in SSH, the SSH daemon needs to of privilege. Programming errors occurring in the un- know the private host key during re-keying to authenti- privileged parts can no longer be abused to gain unau- cate the key exchange. The daemon also needs to open thorized privileges. Privilege separation is orthogonal new pseudo-terminals when the SSH client so requests. to capability systems or application confinement and These operations require durable special privilege as enhances the security of such systems even further. they can be requested at any time during the lifetime Privilege separation is especially useful for system of a SSH connection. In current SSH implementations, services that authenticate users. These services exe- therefore, an exploitable programming error allows an cute privileged operations depending on internal state adversary to obtain superuser privilege. not known to an application confinement mechanism. Several approaches to help prevent security prob- As a concrete example, the concept of privilege sep- lems related to programming errors have been pro- aration has been implemented in OpenSSH. However, posed. Among them are type-safe languages [30] and privilege separation is equally useful for other authen- operating system mechanisms such as protection do- ticating services. We illustrate how separation of priv- mains [11] or application confinement [18, 21, 28]. ileges reduces the amount of OpenSSH code that is ex- However, these solutions do not apply to many exist- ecuted with special privilege. Privilege separation pre- ing applications written in C running on generic Unix vents known security vulnerabilities in prior OpenSSH operating systems. Furthermore, system services that versions including some that were unknown at the time authenticate users are difficult to confine because ex- of its implementation. ecution of privileged operations depends on internal state not known to the sandbox. Instead, this paper discusses the methodology and 1 Introduction design of privilege separation, a generic approach to limit the scope of programming bugs. The basic prin- Services running on computers connected to the In- ciple of privilege separation is to reduce the amount of ternet present a target for adversaries to compromise code that runs with special privilege without affecting their security. This can lead to unauthorized access to or limiting the functionality of the service. This nar- sensitive data or resources. rows the exposure to bugs in code that is executed with Services that require special privilege for their op- privileges. Ideally, the only consequence of an error in eration are critically sensitive. A programming error a privilege separated service is denial of service to the here may allow an adversary to obtain and abuse the adversary himself. special privilege. The principle of separating privileges applies to any The degree of the escalation depends on which priv- privileged service on Unixoperating systems. It is es- ileges the adversary is authorized to hold and which pecially useful for system services that grant authenti- privileges can be obtained in a successful attack. For cated users special privilege. Such services are difficult example, a programming error that permits a user to to confine because the internal state of a service is not USENIX Association 12th USENIX Security Symposium 231 known to an application confinement system and for proaches to application design that help prevent unan- that reason it cannot restrict operations that the ser- ticipated consequences from such errors: defensive pro- vice might perform for authenticated users. As a result, gramming, language enforced protection, and protec- an adversary who gains unauthorized control over the tion mechanisms supported by the operating system. service may execute the same operations as any authen- The latter two approaches are not applicable to ticated user. With privilege separation, the adversary many Unix-like operating systems because they are de- controls only the unprivileged code path and obtains veloped in the C language which lacks type-safety or no unauthorized privilege. other protection enforcement. Though some systems Privilege separation also facilitates source code au- have started to support non-executable stack pages dits by reducing the amount of code that needs to be which prevent many stack overflows from being ex- inspected intensively. While all source code requires ploitable, even this simple mechanism is not available auditing, the size of code that is most critical to secu- for most Unixplatforms. rity decreases. Furthermore, the Unixsecurity model is very coarse In Unix, every process runs within its own protec- grained. Process privileges are organized in a flat tree. tion domain, i.e., the operating system protects the ad- At the root of the tree is the superuser. Its leaves are dress space of a process from manipulation and control the users of the system. The superuser has access to by unrelated users. Using this feature, we accomplish every process, whereas users may not control processes privilege separation by spawning unprivileged children of other users. Privileges that are related to file sys- from a privileged parent. To execute privileged oper- tem access have finer granularity because the system ations, an unprivileged child asks its privileged parent grants access based on the identity of the user and his to execute the operation on behalf of the child. An group memberships. In general, privileged operations adversary who gains control over the child is confined are executed via system calls in the Unix kernel, which in its protection domain and does not gain control over differentiates mainly between the superuser and every- the parent. one else. In this paper, we use OpenSSH as an example of This leaves defensive programming, which attempts a service whose privileges can be separated. We show to prevent errors by checking the integrity of param- that bugs in OpenSSH that led to system compromise eters and data structures at implementation, compile are completely contained by privilege separation. Priv- or run time. For example, defensive programming pre- ilege separation requires small changes to existing code vents buffer overflows by checking that the buffer is and incurs no noticeable performance penalty. large enough to hold the data that is being copied into The rest of the paper is organized as follows. In Sec- it. Improved library interfaces like strlcpy and strlcat tion 2, we discuss the principle of least privilege. We help programmers avoid buffer overflows [17]. introduce the concept of privilege separation in Sec- Nonetheless, for complexapplications it is still in- tion 3 and describe a generic implementation for Unix evitable that programming errors remain. Further- operating system platforms. We explain the implemen- more, even the most carefully written application can tation of privilege separation in OpenSSH in Section 4. be affected by third-party libraries and modules that In Section 5, we discuss how privilege separation im- have not been developed with the same stringency. The proves security in OpenSSH. We analyze performance likelihood of bugs is high, and an adversary will try to impact in Section 6. Section 7 describes related work. use those bugs to gain special privilege. Even if the Finally, we conclude in Section 8. principle of least privilege has been followed, an adver- sary may still gain those privileges that are necessary for the application to operate. 2 Least Privilege We refer to a privilege as a security attribute that 3 Privilege Separation is required for certain operations. Privileges are not unique and may be held by multiple entities. This section presents an approach called privilege The motivation for this effort is the principle of