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()
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

9. 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

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)
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

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

16. 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)

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
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