CITI Technical Report 02-2 Preventing Privilege Escalation Niels Provos [email protected] Abstract Many operating system services require special privileges to execute their tasks. A programming error in a privileged service may open the door to system compromise in form of unauthorized acquisition of privileges. In the worst case, a remote attacker may obtain superuser privileges. In this paper, we discuss the methodology and design of privilege separation, a generic approach that lets parts of an application run without special privileges. Programming errors occurring in these now unprivileged parts of the application can no longer be abused to gain unauthorized privileges. Privilege separation is orthogonal to capability or role-based security systems and may be used to enhance the security of such systems even further. As a concrete example, the concept of privilege separation has been implemented in OpenSSH. We illustrate how separation of privileges reduces the amount of OpenSSH code that is executed with privileges. Privilege separation would have prevented past security vulnerabilities in OpenSSH including those that were unknown at the time of its implementation. August 5, 2002 Center for Information Technology Integration University of Michigan 535 West William Street Ann Arbor, MI 48103-4943 . Preventing Privilege Escalation Niels Provos Center for Information Technology Integration University of Michigan 1 Introduction code that runs with special privileges without affect- ing or limiting the functionality of the service. This Services running on computers connected to the In- reduces the opportunity for bugs in code that is ex- ternet present a target for attackers to compromise ecuted with privileges. Ideally, the only consequence their security. This can lead to unauthorized access of an error in a privilege separated service is denial of of sensitive data or resources. service to the attacker himself. Services that require special privileges for their op- Privilege separation also facilitates source code au- eration are critically sensitive. A programming error dits by reducing the amount of code that needs to be here may allow an attacker to obtain and abuse the inspected initially. While all source code requires au- special privileges. diting, the size of code that is most critical to security The degree of the escalation depends on which privi- decreases. leges the attacker is authorized to hold and which priv- Privilege separation is instantiated by spawning un- ileges can be obtained in a successful attack. For exam- privileged children from a privileged parent. To exe- ple, a programming error that permits a user to gain cute privileged operations, the unprivileged child re- extra privilege after successful authentication limits the quests a privileged operation from the privileged par- degree of escalation because the user is already autho- ent. rized to hold some privileges. On the other hand, a The principle of separating privileges applies to any remote attacker gaining superuser privileges without privileged service on a Unix-like operating system. In any authentication presents a more severe escalation. this paper, we use OpenSSH as an example of a ser- For services that are part of the critical Internet vice whose privileges can be separated. We show that infrastructure is it particularly important to protect bugs in OpenSSH that led to system compromise are against programming errors. Sometimes these services completely contained by privilege separation. Privilege need to retain special privilege for the lifetime of a ses- separation requires small changes to existing code and sion. For example, in SSH, the SSH daemon needs to incurs no noticeable performance penalty. know the private host key during re-keying to authen- The rest of the paper is organized as follows. In Sec- ticate the key exchange. The daemon also needs to tion 2, we discuss the principle of least privilege. We in- open new pseudo-terminals when the SSH client so re- troduce the concept of privilege separation in Section 3 quests. These operations require durable privileges as and describe a generic implementation for Unix operat- they can be requested at any time during the lifetime ing system platforms. We explain the implementation of a SSH connection. In current SSH implementations, of privilege separation in OpenSSH in Section 4. In therefore, an exploitable programming error allows an Section 5, we discuss how privilege separation improves attacker to obtain superuser privileges. security in OpenSSH. We analyze its performance im- Several approaches to help prevent security prob- pact in Section 6. Section 7 describes related work. lems related to programming errors have been pro- Finally, we conclude in Section 8. posed. Among them are type-safe languages [18] and operating system mechanisms like protection do- mains [9]. However, these solutions do not apply to 2 Least Privilege many existing applications as they are written in C to run on a generic Unix operating systems. We refer to a privilege as a security attribute that Instead, this paper discusses the methodology and is required for certain operations. Privileges are not design of privilege separation, a generic approach to unique and may be held by multiple entities. limit the scope of programming bugs. The basic prin- The motivation for this effort is the principle of least ciple of privilege separation is to reduce the amount of privilege: every program and every user should oper- 3 ate using the least amount of privileges necessary to decomposition found in micro-kernels or in Unix com- complete the job [16]. Applying the principle to appli- mand line tools. Privilege separation is orthogonal to cation design limits unintended damage resulting from other protection mechanisms that an operating system programming errors. Linden [11] suggests three ap- might support, e.g., capabilities or protection domains. proaches to application design that help prevent unan- We describe an implementation of privilege separation ticipated consequences from such errors: defensive pro- that does not require special support from the operat- gramming, language enforced protection, and protec- ing system kernel and as such may be implemented on tion mechanisms supported by the operating system. almost any Unix-like operating system. The latter two approaches are not applicable to The goal of privilege separation is to reduce the many Unix-like operating systems because they are de- amount of code that runs with special privileges. We veloped in the C language which lacks type-safety or achieve this by splitting an application into two parts. other protection enforcement. Though some systems One part that runs with privileges and the other that have started to support non-executable stack pages runs without them. We call the privileged part the which prevent many stack overflows from being ex- monitor and the unprivileged part the slave. The slave ploitable, this mechanism is not available for most Unix has to ask the monitor to perform any operation that platforms. requires privileges. Before serving a request from the Furthermore, the Unix security model is very coarse. slave, the monitor first validates it. If the request is Process privileges are organized in a flat tree. At the currently permitted, the monitor executes it and com- root of the tree is the superuser and its leaves are the municates the results back to the slave. users of the system. The superuser has access to ev- In order to separate the privileges in a service, it is ery process, whereas users may not access processes of necessary to identify the operations that require them. other users. Privileges that are related to file system The number of such operations is usually small com- access have finer granularity because the system grants pared to the operations that can be executed without access based on the identity of the user and his group special privileges. Assuming a uniform distribution of memberships. In general, privileged operations are ex- programming errors, privilege separation reduces the ecuted via system calls in the Unix kernel, which dif- number of programming errors that occur in a priv- ferentiates mainly between the superuser and everyone ileged code path. Furthermore, source code auditing else. efforts can be directed towards code that is executed This leaves defensive programming, which attempts with privileges which can further reduce the number of to prevent errors by checking the integrity of param- programming errors remaining in it. eters and data structures at implementation, compile Although errors in the unprivileged code path can or run time. For example, defensive programming pre- not result in any immediate privilege escalation, it vents buffer overflows by checking that the buffer is might still be possible to abuse them for other attacks large enough to hold the data that is being copied into like resource starvation. Such denial of service attacks it. Improved library interfaces like strlcpy and strlcat are beyond the scope of this paper. help programmers avoid buffer overflows [13]. In the following, we explain the Unix mechanisms Nonetheless, for complex applications it is still in- that allow us to implement a privilege separated ser- evitable that programming errors remain. Further- vice. Processes are protection domains in a Unix sys- more, even the most carefully written application can tem. That means that one process can not access data be affected by third-party libraries and modules that in another process. To achieve privilege separation, we have not been developed with the same stringency. The create two entities: a privileged parent process that likelihood of bugs is high, and an attacker will try to acts as the monitor and an unprivileged child process use those bugs to gain unauthorized privileges. Even if that acts as the slave. The privileged parent can be the principle of least privilege has been followed, an at- modeled by a finite-state machine (FSM) that moni- tacker may still gain those privileges that are necessary tors the progress of the unprivileged child.