Preventing Privilege
Escalation
Presented By
Chad Frommeyer
Preventing Privilege Escalation
•
•
•
•
•
•
Introduction
Least Privilege
Privilege Separation
Privilege Separation in OpenSSH
Security/Performance Analysis
Related Work/Conclusion
Introduction
• Programming Errors result in unauthorized
acquisition of privileges
• Privilege Separation allows an application
to run with different levels of privilege
• Privilege Separation is useful for services
that authenticate users
• Privilege Separation Illustration with
OpenSSH
Least Privilege
• Privilege – a security attribute that is
required for certain operations
• Least Privilege – every program and every
user should operate using the least
amount of privilege to complete the job
• Most approaches including least privilege
are still susceptible to programming errors
Privilege Separation
• Separates applications into privileged and
unprivileged parts
• Separation is independent of operating
system protections
• Reduces the amount of code running
under special privileges
• Accomplished by Monitor/Slave
Techniques
Privilege Separation
• Reduces the number of programming
errors in privileged sections
• Security source code audits can be more
focused and thorough
• Abuse that is successful usually only
results in denial of services not high
privileged access
Privilege Separation
• Phases
– Pre-Authentication Phase
• User has contacted the system service but is not
yet authenticated
– Post-Authentication Phase
• User has successfully authenticated to the system
• Child process maintains the privileges of the
authenticated user
Privilege Separation
• Issues with Implementation
– How to communicate from Monitor to Slave
– How to pass data from Monitor to Slave
– How to change user identity of the slave
process
– How to validate the slave’s request
Privilege Separation
Separating Privileges in OpenSSH
Separating Privileges in OpenSSH
• Pre-Authentication Phase
– Key Exchange
– Authenticated Key Exchange
– User Validation
– Password authentication
– Public Key Authentication
• Slave changes identity after PreAuthentication phase completes
successfully
Separating Privileges in OpenSSH
• Post-Authentication Phase
– Key Exchange
– Pseudo terminal Creation
• Alternative Design
– Add an additional Child process to handle
network traffic
– Child processes can communicate
– Removes the need to export state and use
shared memory
Separating Privileges in OpenSSH
• Separating Privileges had the following
effects
– Increased source code size, reduced code
complexity
– Interface improvement
– Better code organization
– Less complex and easier to understand
– Opens ability to support security critical
source code reusability (Libraries)
Security/Performance Analysis
Security/Performance Analysis
• Potential Problems Still exist by the slave being
compromised
–
–
–
–
–
Use Signal or Ptrace to gain additional access
Gain access to the file system
Gain access to network connections
Gain access to privileged system information
Effect the Monitor by accessing the Monitor/Slave
communication method
– Starve the system by continually forking processes
Security/Performance Analysis
• Past Security Issues
– A number of security issues in SSH-1 have
been shown to be contained when privilege
separation was implemented
•
•
•
•
CRC32 Compensation Atack
Off by one error
Zlib compression security problem
Kerberos ticket passing
Security/Performance Analysis
Related Work/Conclusion
• Least privilege allows privileged code to
an adversary, Privilege separation doesn’t
• Other applications that use similar
techniques
– Postfix
– Evans very secure FTP
– Solar Designer
Related Work/Conclusion
• Programming errors in privileged services
give an adversary unauthorized privileges
• With privilege separation, only
unprivileged parts are accessible to
adversaries
• OpenSSH is working proof to the success
of this concept
• Performance is not compromised