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

Pre-Authentication Phase –Key Exchange –Authenticated Key Exchange –User Validation –Password authentication –Public Key Authentication Slave changes identity after Pre- Authentication 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

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