Preventing Privilege Escalation

1. Preventing Privilege Escalation N. Provos, M. Friedl, P. Honyman

2. The Problem • Internet and distributed applications execute services on behalf of a remote user • These services run as a task/process on the operating system • The task runs with a set amount of privilege • Programming errors may lead to unauthorized and/or unintentional acquisition of privileges on a remote machine • A compromise due to acquisition of unauthorized privileges can lead to very bad things since the servicing processes often run with superuser (e.g., root) privileges

3. Preventing Errors that Lead to Users Gaining Unauthorized Privilege • Defensive programming • Programming language enforced protection • Use protection mechanisms provided by the operating system

4. Preventing Errors that Lead to Users Gaining Unauthorized Privilege • YES, but Problems on the Unix Platform • Programming language enforced protection • Most programs are written in “C” which is not a type safe language • Use protection mechanisms provided by the operating system • Unix security tends to be very course grained (except for the file system) – operations allowed by the kernel, and operations allowed by all other processes. • Most Unix distributions have executable stack frames • Defensive programming • Since most programs are written in “C” its up to the user to make sure that things like strncpy() are used instead of strcpy(), etc.

5. Providing Protection via Design • Use the principle of least privilege • “Every program or user should operate using the least amount of privilege necessary to complete the job” • Design using privilege separation • Partition a program into “parts” based on required privileges • Use the principle of least privilege on the “parts”

6. Privilege Separation • Reduce the amount of code that runs with special privilege • The MONITOR is the privileged part of the code and the SLAVE(S) are the unprivileged part(s) of the code • Reduces the amount of code that executes with elevated privileges • Reduces the amount of code that needs to be audited Privilege Separation is useful in applications where individual users need to be authenticated and authorized

7. Engineering Privilege Separation in Unix • Processes are protection domains • One process cannot control another unrelated process • A parent process can control a child process Start – fork() MONITOR SLAVE IPC Privileged Unprivileged

8. Engineering Privilege Separation in Unix Start – fork() • The exchange protocol (interface) and information hiding are important in this type of design • INTERFACE: The monitor executes requests on behalf of the slave(s) after it validates the request from the slave • INFORMATION HIDING: The monitor never provides privileged information to the slaves MONITOR SLAVE IPC Privileged Unprivileged

9. Pre and Post Authentication Phases Pre-Authentication Post-Authentication MONITOR NewRequest MONITOR OperatingSystem MONITOR Allowed SLAVE(UID/GID) OperatingSystem Allowed SLAVE Note: Slave has UID/GIDOperating System Privilegesbased on providedcredentials All FutureClient Requests Note: Slave has NO OperatingSystem Privileges

10. Pre and Post Authentication (con’t) • Pre-Authentication • The Monitor creates a slave • The slave gets a null file system and no OS privileges based on its UID/GID • The slave can only interface with the monitor • Post-Authentication • The slave eventually authenticates with the monitor • The slave UID/GID and file system access to the OS is altered based on the identity of the authenticated user • The slave must use the monitor to execute privileged operations on its behalf, and it may directly execute operations that it is privileged to perform

11. Switching the Identity of the Slave • Few OS support an API to change the identity of an executing process • General Approach • Serialize the slave’s state • Have the monitor create a new slave with appropriate GID, UID and file system privilege • Restore the state of the slave • Might used shared memory for dynamically allocated storage to simplify restoring the slave’s state

12. IPC between the Monitor and the Slave • The monitor must accept and execute requests from the slave • Use an operating system supported Interprocess Communication facility supported by the OS • Generally anonymous pipes (shared file system descriptors) are used • File handles created by the monitor are mapped into the slaves address space

13. Case Study: Open SSH • SSH establishes a secure pipe for remote terminal and file system operations • All traffic from the client to the remote server is encrypted • Unlike ftp and telnet the userid and password is also encrypted over the network channel • SSH runs as a daemon with super user privileges, however, all client requests, post authentication, run using the clients’ credentials

14. The SSH design – Privilege Separation SSHD(Port 22) ProtectedFiles Notice howthe slavecannot accessthese files PREAuthenticatedClient Requests fork() MONITOR SLAVE (no privilege) RequestPrivileged Operations Request PrivilegedOperations fork_w_newIdentity() POSTAuthenticatedClient Requests SLAVE Client Identity OperatingSystem Based OnUser’s Identity

15. SSH Privileged Operations • Pre-Authentication • Key Exchange • Key Authentication • User Validation • Password Authentication • Post-Authentication • Key Exchange – if the keys get updated • New Terminal Creation Notice, at no time does the slave have direct access tokey and password databases/files

16. SSH Design Improvement – Post Authentication SSHD(Port 22) Slave 1 is responsiblefor network trafficencryption/decryption fork() MONITOR Slave 2 is responsiblefor executing usershell commands fork() fork() SLAVE 1 No Privilege SLAVE 2 Client Identity This design allows encryption and decryption to run withlower privileges (less than the client itself)

17. SSH Evolution • Implementing privilege separation in OpenSSH required only changing 950 lines of code • Total code-base is 44K so change constituted ~2% of the code • This design can be extended to allow for SSH to tunnel additional remote services (since the monitor separate from slave) • Example: Remote X-Windows

18. Security Analysis • With Privilege Separation • 2/3 of codebase runs with lower privilege • 1/3 requires superuser privilege • Includes 3rd party library code • Without 3rd party libraries OpenSSH has 75% of its codebase executing without special privileges • Reduces the amount of code to audit dramatically • Special emphasis must be placed on the interface between the monitor and slave(s) but this is only a very small percentage of the codebase • Want to avoid the slave getting control over the monitor

19. Security Analysis – Privilege Separation Problems Avoided • Users gaining unauthorized access to resources • The slave is protected by the OS with specific capabilities based on the UID/GID • Slave probes other slave processes • Protected by OS • Slave queries OS • Dependant on OS capabilities to prevent • Slave modifies the file system • Protected by OS • Slave performs denial of service by using too many resources • Use quota’s on the slave processes

20. Limitations of Privilege Separation • A compromised AUTHENTICATED slave is allowed to perform tasks based on the credentials of the authenticated user • It is assumed that the protection mechanisms offered by the operating system work as advertised

21. Performance Analysis • OpenSSH suffers no performance penalty based on using a privilege separation • Most of the expensive operations are performed by the slave post-authentication • This is the same as in the non privileged separation design • Requests to the monitor are not data or processing intensive and are rare

22. Summary • For certain applications using privilege separation is a good approach towards implementing secure software • Its always good to use the principle of least privilege when designing internet or distributed applications • Future OS designs should support additional capabilities to enable privilege separation • Example: An API to change the user’s identity