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

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

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

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.

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”

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

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

Engineering Privilege Separation in Unix Start – fork() MONITOR SLAVE IPC Privileged Unprivileged 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

Pre and Post Authentication Phases Pre-Authentication Post-Authentication MONITOR New Request MONITOR MONITOR Operating System Allowed Operating System SLAVE (UID/GID) Allowed SLAVE All Future Client Requests Note: Slave has UID/GID Operating System Privileges based on provided credentials Note: Slave has NO Operating System Privileges

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

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

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

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

The SSH design – Privilege Separation SSHD (Port 22) Protected Files Notice how the slave cannot access these files PRE Authenticated Client Requests fork() MONITOR SLAVE (no privilege) Request Privileged Operations Request Privileged Operations fork_w_newIdentity() POST Authenticated Client Requests SLAVE Client Identity Operating System Based On User’s Identity

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 to key and password databases/files

SSH Design Improvement – Post Authentication SSHD (Port 22) Slave 1 is responsible for network traffic encryption/decryption fork() MONITOR Slave 2 is responsible for executing user shell commands fork() fork() SLAVE 1 No Privilege SLAVE 2 Client Identity This design allows encryption and decryption to run with lower privileges (less than the client itself)

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

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

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 Slave performs denial of service by using too many resources Use quota’s on the slave processes

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

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

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