Preventing Privilege Escalation

Slides:



Advertisements
Similar presentations
Operating Systems Components of OS
Advertisements

Operating System Structures
Slide 2-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 2 Using the Operating System 2.
(Remote Access Security) AAA. 2 Authentication User named "flannery" dials into an access server that is configured with CHAP. The access server will.
1 CSE 380 Computer Operating Systems Instructor: Insup Lee and Dianna Xu University of Pennsylvania Fall 2003 Lecture Note: Protection Mechanisms.
Guide To UNIX Using Linux Third Edition
TCP/IP - Security Perspective Upper Layers CS-431 Dick Steflik.
Copyright Arshi Khan1 System Programming Instructor Arshi Khan.
AN INTRODUCTION TO LINUX OPERATING SYSTEM Zihui Han.
Computation for Physics 計算物理概論 Introduction to Linux.
Systems Security & Audit Operating Systems security.
Chapter 6 Operating System Support. This chapter describes how middleware is supported by the operating system facilities at the nodes of a distributed.
Remote Access Chapter 4. Learning Objectives Understand implications of IEEE 802.1x and how it is used Understand VPN technology and its uses for securing.
Remote Access Chapter 4. Learning Objectives Understand implications of IEEE 802.1x and how it is used Understand VPN technology and its uses for securing.
Composition and Evolution of Operating Systems Introduction to Operating Systems: Module 2.
14.1 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 14: Protection Goals of Protection Principles of Protection Domain of Protection.
4P13 Week 1 Talking Points. Kernel Organization Basic kernel facilities: timer and system-clock handling, descriptor management, and process Management.
Network Security. 2 SECURITY REQUIREMENTS Privacy (Confidentiality) Data only be accessible by authorized parties Authenticity A host or service be able.
CE Operating Systems Lecture 3 Overview of OS functions and structure.
Computer Networking From LANs to WANs: Hardware, Software, and Security Chapter 13 FTP and Telnet.
Distributed System Concepts and Architectures 2.3 Services Fall 2011 Student: Fan Bai
Linux Security. Authors:- Advanced Linux Programming by Mark Mitchell, Jeffrey Oldham, and Alex Samuel, of CodeSourcery LLC published by New Riders Publishing.
UNIX System Protection. Unix History Developed by Dennis Ritchie and Ken Thompson at AT&T Bell Labs Adapted some ideas from the Multics project in 1969.
Preventing Privilege Escalation Presented By Chad Frommeyer.
UNIX Unit 1- Architecture of Unix - By Pratima.
Processes and Virtual Memory
Security Architecture of qmail and Postfix Authors: Munawar Hafiz Ralph E. Johnson Prepared by Geoffrey Foote CSC 593 Secure Software Engineering Seminar.
File Transfer And Access (FTP, TFTP, NFS). Remote File Access, Transfer and Storage Networks For different goals variety of approaches to remote file.
Distributed Systems Ryan Chris Van Kevin. Kinds of Systems Distributed Operating System –Offers Transparent View of Network –Controls multiprocessors.
Silberschatz, Galvin and Gagne ©2011 Operating System Concepts Essentials – 8 th Edition Chapter 2: The Linux System Part 5.
Lecture 14 Page 1 CS 236 Online Secure Programming CS 236 On-Line MS Program Networks and Systems Security Peter Reiher.
Computer System Structures
Operating Cisco IOS Software
Chapter 4 – Thread Concepts
Secure services Unit-IV CHAP-1
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
© 2002, Cisco Systems, Inc. All rights reserved.
Protecting Memory What is there to protect in memory?
Chapter 14: System Protection
Protecting Memory What is there to protect in memory?
Protecting Memory What is there to protect in memory?
Outline What does the OS protect? Authentication for operating systems
Module 4 Remote Login.
Chapter 4 – Thread Concepts
Operating System Structure
Introduction to Operating System (OS)
INTER-PROCESS COMMUNICATION
Outline What does the OS protect? Authentication for operating systems
KERNEL ARCHITECTURE.
Chapter 3: Windows7 Part 4.
2P13 Week 2.
Chapter 27: System Security
Chapter 14: Protection.
Chapter 2: The Linux System Part 2
Chapter 2: System Structures
CGS 3763 Operating Systems Concepts Spring 2013
Chapter 3: Operating-System Structures
UNIX System Protection
SECURITY IN THE LINUX OPERATING SYSTEM
Threads Chapter 4.
Chapter 2: Operating-System Structures
Chapter 2: The Linux System Part 5
Security.
Chapter 14: Protection.
Introduction to Operating Systems
Prof. Leonardo Mostarda University of Camerino
Designing IIS Security (IIS – Internet Information Service)
Chapter 2: Operating-System Structures
Grid Computing Software Interface
Least-Privilege Isolation: The OKWS Web Server
Presentation transcript:

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