DOCSLIB.ORG

Preventing Privilege Escalation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Preventing Privilege Escalation CITI Technical Report 02-2 Preventing Privilege Escalation Niels Provos [email protected] Abstract Many operating system services require special privileges to execute their tasks. A programming error in a privileged service may open the door to system compromise in form of unauthorized acquisition of privileges. In the worst case, a remote attacker may obtain superuser privileges. In this paper, we discuss the methodology and design of privilege separation, a generic approach that lets parts of an application run without special privileges. Programming errors occurring in these now unprivileged parts of the application can no longer be abused to gain unauthorized privileges. Privilege separation is orthogonal to capability or role-based security systems and may be used to enhance the security of such systems even further. As a concrete example, the concept of privilege separation has been implemented in OpenSSH. We illustrate how separation of privileges reduces the amount of OpenSSH code that is executed with privileges. Privilege separation would have prevented past security vulnerabilities in OpenSSH including those that were unknown at the time of its implementation. August 5, 2002 Center for Information Technology Integration University of Michigan 535 West William Street Ann Arbor, MI 48103-4943 . Preventing Privilege Escalation Niels Provos Center for Information Technology Integration University of Michigan 1 Introduction code that runs with special privileges without affect- ing or limiting the functionality of the service. This Services running on computers connected to the In- reduces the opportunity for bugs in code that is ex- ternet present a target for attackers to compromise ecuted with privileges. Ideally, the only consequence their security. This can lead to unauthorized access of an error in a privilege separated service is denial of of sensitive data or resources. service to the attacker himself. Services that require special privileges for their op- Privilege separation also facilitates source code au- eration are critically sensitive. A programming error dits by reducing the amount of code that needs to be here may allow an attacker to obtain and abuse the inspected initially. While all source code requires au- special privileges. diting, the size of code that is most critical to security The degree of the escalation depends on which privi- decreases. leges the attacker is authorized to hold and which priv- Privilege separation is instantiated by spawning un- ileges can be obtained in a successful attack. For exam- privileged children from a privileged parent. To exe- ple, a programming error that permits a user to gain cute privileged operations, the unprivileged child re- extra privilege after successful authentication limits the quests a privileged operation from the privileged par- degree of escalation because the user is already autho- ent. rized to hold some privileges. On the other hand, a The principle of separating privileges applies to any remote attacker gaining superuser privileges without privileged service on a Unix-like operating system. In any authentication presents a more severe escalation. this paper, we use OpenSSH as an example of a ser- For services that are part of the critical Internet vice whose privileges can be separated. We show that infrastructure is it particularly important to protect bugs in OpenSSH that led to system compromise are against programming errors. Sometimes these services completely contained by privilege separation. Privilege need to retain special privilege for the lifetime of a ses- separation requires small changes to existing code and sion. For example, in SSH, the SSH daemon needs to incurs no noticeable performance penalty. know the private host key during re-keying to authen- The rest of the paper is organized as follows. In Sec- ticate the key exchange. The daemon also needs to tion 2, we discuss the principle of least privilege. We in- open new pseudo-terminals when the SSH client so re- troduce the concept of privilege separation in Section 3 quests. These operations require durable privileges as and describe a generic implementation for Unix operat- they can be requested at any time during the lifetime ing system platforms. We explain the implementation of a SSH connection. In current SSH implementations, of privilege separation in OpenSSH in Section 4. In therefore, an exploitable programming error allows an Section 5, we discuss how privilege separation improves attacker to obtain superuser privileges. security in OpenSSH. We analyze its performance im- Several approaches to help prevent security prob- pact in Section 6. Section 7 describes related work. lems related to programming errors have been pro- Finally, we conclude in Section 8. posed. Among them are type-safe languages [18] and operating system mechanisms like protection do- mains [9]. However, these solutions do not apply to 2 Least Privilege many existing applications as they are written in C to run on a generic Unix operating systems. We refer to a privilege as a security attribute that Instead, this paper discusses the methodology and is required for certain operations. Privileges are not design of privilege separation, a generic approach to unique and may be held by multiple entities. limit the scope of programming bugs. The basic prin- The motivation for this effort is the principle of least ciple of privilege separation is to reduce the amount of privilege: every program and every user should oper- 3 ate using the least amount of privileges necessary to decomposition found in micro-kernels or in Unix com- complete the job [16]. Applying the principle to appli- mand line tools. Privilege separation is orthogonal to cation design limits unintended damage resulting from other protection mechanisms that an operating system programming errors. Linden [11] suggests three ap- might support, e.g., capabilities or protection domains. proaches to application design that help prevent unan- We describe an implementation of privilege separation ticipated consequences from such errors: defensive pro- that does not require special support from the operat- gramming, language enforced protection, and protec- ing system kernel and as such may be implemented on tion mechanisms supported by the operating system. almost any Unix-like operating system. The latter two approaches are not applicable to The goal of privilege separation is to reduce the many Unix-like operating systems because they are de- amount of code that runs with special privileges. We veloped in the C language which lacks type-safety or achieve this by splitting an application into two parts. other protection enforcement. Though some systems One part that runs with privileges and the other that have started to support non-executable stack pages runs without them. We call the privileged part the which prevent many stack overflows from being ex- monitor and the unprivileged part the slave. The slave ploitable, this mechanism is not available for most Unix has to ask the monitor to perform any operation that platforms. requires privileges. Before serving a request from the Furthermore, the Unix security model is very coarse. slave, the monitor first validates it. If the request is Process privileges are organized in a flat tree. At the currently permitted, the monitor executes it and com- root of the tree is the superuser and its leaves are the municates the results back to the slave. users of the system. The superuser has access to ev- In order to separate the privileges in a service, it is ery process, whereas users may not access processes of necessary to identify the operations that require them. other users. Privileges that are related to file system The number of such operations is usually small com- access have finer granularity because the system grants pared to the operations that can be executed without access based on the identity of the user and his group special privileges. Assuming a uniform distribution of memberships. In general, privileged operations are ex- programming errors, privilege separation reduces the ecuted via system calls in the Unix kernel, which dif- number of programming errors that occur in a priv- ferentiates mainly between the superuser and everyone ileged code path. Furthermore, source code auditing else. efforts can be directed towards code that is executed This leaves defensive programming, which attempts with privileges which can further reduce the number of to prevent errors by checking the integrity of param- programming errors remaining in it. eters and data structures at implementation, compile Although errors in the unprivileged code path can or run time. For example, defensive programming pre- not result in any immediate privilege escalation, it vents buffer overflows by checking that the buffer is might still be possible to abuse them for other attacks large enough to hold the data that is being copied into like resource starvation. Such denial of service attacks it. Improved library interfaces like strlcpy and strlcat are beyond the scope of this paper. help programmers avoid buffer overflows [13]. In the following, we explain the Unix mechanisms Nonetheless, for complex applications it is still in- that allow us to implement a privilege separated ser- evitable that programming errors remain. Further- vice. Processes are protection domains in a Unix sys- more, even the most carefully written application can tem. That means that one process can not access data be affected by third-party libraries and modules that in another process. To achieve privilege separation, we have not been developed with the same stringency. The create two entities: a privileged parent process that likelihood of bugs is high, and an attacker will try to acts as the monitor and an unprivileged child process use those bugs to gain unauthorized privileges. Even if that acts as the slave. The privileged parent can be the principle of least privilege has been followed, an at- modeled by a finite-state machine (FSM) that moni- tacker may still gain those privileges that are necessary tors the progress of the unprivileged child.
Load more

Recommended publications
  • Least Privilege and Privilege Separation
    CSE 127: Computer Security Least privilege and privilege separation Deian Stefan Slides adopted from John Mitchell, Dan Boneh, and Stefan Savage This week… • How to build secure systems ➤ Least privilege and privilege separation ➤ Sandboxing and isolation • Key is underlying principles not mechanisms ➤ We’re going to look at systems techniques ➤ Other ways to achieve similar goals: language-based Principles of secure design • Principle of least privilege • Privilege separation • Defense in depth ➤ Use more than one security mechanism ➤ Fail securely/closed • Keep it simple Principles of secure design • Principle of least privilege • Privilege separation • Defense in depth ➤ Use more than one security mechanism ➤ Fail securely/closed • Keep it simple Principle of Least Privilege Defn: A system should only have the minimal privileges needed for its intended purposes • What’s a privilege? ➤ Ability to access (e.g., read or write) a resource Principle of Least Privilege Defn: A system should only have the minimal privileges needed for its intended purposes • What’s a privilege? ➤ Ability to access (e.g., read or write) a resource Principle of Least Privilege Defn: A system should only have the minimal privileges needed for its intended purposes • What’s a privilege? ➤ Ability to access (e.g., read or write) a resource What’s the problem with this defn? • Talking about a huge, monolith system is not really useful • Why? Network Network User input User device File system File system Breaking a system into components • Compartmentalization and isolation ➤ Separate the system into isolated compartments ➤ Limit interaction between compartments • Why is this more meaningful? Network Network User input User device File system File system How dow we break things apart? Map compartment to user ids! • Recall: permissions in UNIX granted according to UID ➤ A process may access files, network sockets, ….
    [Show full text]
  • New Concept of the Android Keystore Service with Regard to Security and Portability
    University of Bremen Department of Mathematics and Computer Science New concept of the Android keystore service with regard to security and portability. Master’s Thesis by Fritjof Bornebusch reviewed by Dr. Karsten Sohr Prof. Dr. Jan Peleska supervised by Dipl. Inf. Florian Junge 2016 Confirmation I hereby confirm that I wrote this master thesis on my own and that I have used only the indicated references, resources, and aids. In German: Hiermit bestätige ich, dass ich die vorliegende Masterthesis selbstständig verfasst, und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Bremen, 1/13/2016 Fritjof Bornebusch “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler – Bornebusch, Fritjof New concept of the Android keystore service with regard to security and portability. Master’s thesis, Department 3 - Mathematics / Computer Science University of Bremen, 2015 This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0). To view a copy of this license, send an email to [email protected], visit http://creativecommons.org/licenses/by-nc-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, California, 94042, USA. Table of Contents Acknowledgements 7 List of Figures 9 List of Listings 10 Acronyms 13 Glossary 15 1 Introduction 19 2 Background 24 2.1 Android System Architecture . 24 2.1.1 Security-Enhanced Linux . 28 2.1.2 Capabilities . 31 2.2 Memory Vulnerabilities . 32 2.2.1 Buffer Overflow Protection . 33 2.2.2 Dead Store Elimination .
    [Show full text]
  • Integration of Security Measures and Techniques in an Operating System (Considering Openbsd As an Example)
    Motivation Security Solutions and Techniques Summary Integration of Security Measures and Techniques in an Operating System (considering OpenBSD as an example) Igor Boehm Institute for Information Processing and Microprocessor Technology Johannes Kepler University Linz, Austria Igor Boehm Integration of Security Measures and Techniques in an OS Motivation Security Solutions and Techniques Summary Outline 1 Motivation The Basic Problem Being Studied Preliminary Solution Ideas and Goals 2 Security Solutions and Techniques Secure Software Design Techniques Memory Protection Techniques Relevance of Random Numbers for Security Igor Boehm Integration of Security Measures and Techniques in an OS Motivation The Basic Problem Being Studied Security Solutions and Techniques Preliminary Solution Ideas and Goals Summary Outline 1 Motivation The Basic Problem Being Studied Preliminary Solution Ideas and Goals 2 Security Solutions and Techniques Secure Software Design Techniques Memory Protection Techniques Relevance of Random Numbers for Security Igor Boehm Integration of Security Measures and Techniques in an OS Motivation The Basic Problem Being Studied Security Solutions and Techniques Preliminary Solution Ideas and Goals Summary The Basic Problem Being Studied The Clever Attacker: . finds a bug . knows how to craft an exploit . the exploit grants the attacker an advantage . the exploit is likely to work on many systems because of the strict regularity of the system environment Is there a way to solve this problem? Igor Boehm Integration of Security
    [Show full text]
  • VULNERABLE by DESIGN: MITIGATING DESIGN FLAWS in HARDWARE and SOFTWARE Konoth, R.K
    VU Research Portal VULNERABLE BY DESIGN: MITIGATING DESIGN FLAWS IN HARDWARE AND SOFTWARE Konoth, R.K. 2020 document version Publisher's PDF, also known as Version of record Link to publication in VU Research Portal citation for published version (APA) Konoth, R. K. (2020). VULNERABLE BY DESIGN: MITIGATING DESIGN FLAWS IN HARDWARE AND SOFTWARE. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal ? Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. E-mail address: [email protected] Download date: 07. Oct. 2021 VULNERABLE BY DESIGN: MITIGATING DESIGN FLAWS IN HARDWARE AND SOFTWARE PH.D. THESIS RADHESH KRISHNAN KONOTH VRIJE UNIVERSITEIT AMSTERDAM, 2020 Faculty of Science The research reported in this dissertation was conducted at the Faculty of Science — at the Department of Computer Science — of the Vrije Universiteit Amsterdam This work was supported by the MALPAY consortium, consisting of the Dutch national police, ING, ABN AMRO, Rabobank, Fox-IT, and TNO.
    [Show full text]
  • Free, Functional, and Secure
    Free, Functional, and Secure Dante Catalfamo What is OpenBSD? Not Linux? ● Unix-like ● Similar layout ● Similar tools ● POSIX ● NOT the same History ● Originated at AT&T, who were unable to compete in the industry (1970s) ● Given to Universities for educational purposes ● Universities improved the code under the BSD license The License The license: ● Retain the copyright notice ● No warranty ● Don’t use the author's name to promote the product History Cont’d ● After 15 years, the partnership ended ● Almost the entire OS had been rewritten ● The university released the (now mostly BSD licensed) code for free History Cont’d ● AT&T launching Unix System Labories (USL) ● Sued UC Berkeley ● Berkeley fought back, claiming the code didn’t belong to AT&T ● 2 year lawsuit ● AT&T lost, and was found guilty of violating the BSD license History Cont’d ● BSD4.4-Lite released ● The only operating system ever released incomplete ● This became the base of FreeBSD and NetBSD, and eventually OpenBSD and MacOS History Cont’d ● Theo DeRaadt ○ Originally a NetBSD developer ○ Forked NetBSD into OpenBSD after disagreement the direction of the project *fork* Innovations W^X ● Pioneered by the OpenBSD project in 3.3 in 2002, strictly enforced in 6.0 ● Memory can either be write or execute, but but both (XOR) ● Similar to PaX Linux kernel extension (developed later) AnonCVS ● First project with a public source tree featuring version control (1995) ● Now an extremely popular model of software development anonymous anonymous anonymous anonymous anonymous IPSec ● First free operating system to implement an IPSec VPN stack Privilege Separation ● First implemented in 3.2 ● Split a program into processes performing different sub-functions ● Now used in almost all privileged programs in OpenBSD like httpd, bgpd, dhcpd, syslog, sndio, etc.
    [Show full text]
  • Make Least Privilege a Right
    Make Least Privilege a Right (Not a Privilege) Maxwell Krohn∗, Petros Efstathopoulosy, Cliff Frey∗, Frans Kaashoek∗, Eddie Kohlery, David Mazieres` z, Robert Morris∗, Michelle Osbornez, Steve VanDeBogarty and David Ziegler∗ ∗MIT yUCLA zNYU [email protected] ABSTRACT ized mandatory access control [17]. The end result is a Though system security would benefit if programmers new operating system called Asbestos. routinely followed the principle of least privilege [24], 2 LESSONS FROM CURRENT SYSTEMS the interfaces exposed by operating systems often stand in the way. We investigate why modern OSes thwart se- Administrators and programmers can achieve POLP by cure programming practices and propose solutions. pushing the features in modern Unix-like operating sys- tems, but only partially, and with important practical 1 INTRODUCTION drawbacks. Though many software developers simultaneously revere 2.1 chrooting or jailing Greedy Applications and ignore the principles of their craft, they reserve spe- cial sanctimony for the principle of least privilege, or Because Unix grants privilege with coarse granularity, POLP [24]. All programmers agree in theory: an applica- many Unix applications acquire more privileges than tion should have the minimal privilege needed to perform they require. These “greedy applications” can be tamed its task. At the very least, five POLP requirements must with the chroot or jail system calls. Both calls con- be followed: (1) split applications into smaller protec- fine applications to jails, areas of the file system that tion domains, or “compartments”; (2) assign exactly the administrators can configure to exclude setuid executa- right privileges to each compartment; (3) engineer com- bles and sensitive files.
    [Show full text]
  • Privilege Separation Made Easy
    Privilege separation made easy Trusting small libraries not big processes Derek G. Murray Steven Hand University of Cambridge Computer Laboratory University of Cambridge Computer Laboratory Cambridge, United Kingdom Cambridge, United Kingdom [email protected] [email protected] ABSTRACT practices” for security. Therefore, we present a new ap- At the heart of a secure software system is a small, trustwor- proach, based on the well-understood and commonly-used thy component, called the Trusted Computing Base (TCB). concept of dynamic libraries. However, developers persist in building monolithic systems Several researchers have discussed the problem of divid- that force their users to trust the entire system. We posit ing a monolithic piece of software into several smaller pieces, that this is due to the lack of a straightforward mechanism of each of which runs with the least necessary privilege. Disag- partitioning – or disaggregating – systems into trusted and gregation [16], partitioning [8], privilege separation [17] and untrusted components. We propose to use dynamic libraries TCB-reduction [13, 21] are simply different names for the as the unit of disaggregation, because these are a familiar process of dividing software into a small trusted computing abstraction, which is commonly used in mainstream software base (TCB), and a larger untrusted part. However, existing development. solutions to this problem either use ad hoc techniques or In this paper, we present our early ideas on the disag- source code annotation to split the code. gregated library approach, which can be applied to existing Dynamic libraries – i.e. collections of executable code and applications that run on commodity operating systems.
    [Show full text]
  • Writing Exploit-Resistant Code with Openbsd Lawrence Teo Lteo Openbsd.Org @Lteo
    Writing Exploit-Resistant Code with OpenBSD Lawrence Teo lteo openbsd.org @lteo Slides and references at: https://lteo.net/carolinacon15 CarolinaCon 15 - Charlotte, NC - April 27, 2019 A question Innovation’s Black Hole Security vulnerabilities Image Credit: EHT Collaboration https://www.eso.org/public/images/eso1907a/ What is OpenBSD? • Free, multi-platform UNIX-liKe operating system • Founded by Theo de Raadt in 1995 • Secure by default • A research operating system • Two releases per year • You’re very liKely using OpenBSD code everyday • OpenSSH • LibreSSL • tmux • More: openbsd.org/innovations.html • Coolest mascot ever whoami • OpenBSD developer since 2012 • Primarily areas related to networking • PF, networK stacK, libpcap, tcpdump, etc. • Userland stuff, ports, man pages, etc • Co-founder, Calyptix Security • Shipping thousands of OpenBSD-based firewalls from Charlotte since 2006! • Ph.D. from UNC Charlotte (2006) • Research area: Info sharing for intrusion detection Auditing Software vulnerabilities How OpenBSD attacks the software vulnerability problem (my view) Auditing Exploit Software Mitigation vulnerabilities Techniques How OpenBSD attacks the software vulnerability problem (my view) Auditing Exploit Software Mitigation vulnerabilities Techniques Rigorous Development Process How OpenBSD attacks the software vulnerability problem (my view) Licensing Auditing Exploit Software Mitigation vulnerabilities Techniques Rigorous Development Process How OpenBSD attacks the software vulnerability problem (my view) Licensing Education
    [Show full text]
  • Pledge and Privsep
    Pledge: where did it come from? Was pledge invented in a light happy dream? „ We stood beneath an amber moon Where hearts were entertaining June And softly whispered "someday soon" We kissed and clung together … “ No, it is the outcome of nightmares. My nightmares ● When Good Instructions go Bad: Generalizing return- oriented programming to RISC – Buckanan, Roemer, Shacham, Savage. 2008. ● Hacking Blind (BROP) – Bittau, Belay, Mashtizadeh, Mazières, Boneh. 2014. ROP – Return Oriented Programming Hijack control-flow with false return frames, running gadgets, combining artifacts effects Gadget is any sequence of register/memory transfer above a true ret (or polymorphic ret) instruction Attacker needs to know where gadgets are, and address of the new-stack Also JOP, SROP, etc. BROP – Blind ROP An address-space oracle Repeated probes against reused address-space learns enough to perform minimum ROP operations Then uses various ROP methods. (Large) software will never be perfect Erroneous condition logic fails, then cascades through successive failures, often externally controllable Results in illegal access/control of the program & libraries, or toying with kernel surface Attacker tools and knowledge are improving, faster than developers can cope I work on mitigations Mitigations are inexpensive tweaks which impact attack methods – trying to diminishing their effectiveness Some mitigations expose use of un-standardized behaviours Defect detected ―> Fail Closed Pressure towards robustness in software. Robust (adj.) „ When used to describe software or computer systems, robust can describe one or more of several qualities: – a system that does not break down easily or is not wholly affected by a single application failure – a system that either recovers quickly from or holds up well under exceptional circumstances – a system that is not wholly affected by a bug in one aspect of it “ On the way to the lush valley of robust, we must first cross the wilderness of fail-closed.
    [Show full text]
  • Principle of Least Privilege
    CSMC 412 Operating Systems Prof. Ashok K Agrawala Set 19 Protection • Goals of Protection • Principles of Protection • Protection Rings • Domain of Protection • Access Matrix • Implementation of Access Matrix • Revocation of Access Rights • Role-based Access Control • Mandatory Access Control (MAC) • Capability-Based Systems • Other Protection Implementation Methods • Language-based Protection Copyright 2018 Silberschatz, Galvin and Gagne Objectives • Discuss the goals and principles of protection in a modern computer system • Explain how protection domains combined with an access matrix are used to specify the resources a process may access • Examine capability and language-based protection systems • Describe how protection mechanisms can mitigate system attacks Copyright 2018 Silberschatz, Galvin and Gagne Security Vs. Protection • Security – • Guarding computer resources against unauthorized access, malicious destruction or alteration, and accidental introduction of inconsistency. • Protection – • Controlling the access of processes and users to the resources defined by a computer system. • System is secure if resources used and accessed as intended under all circumstances • Unachievable Copyright 2018 Silberschatz, Galvin and Gagne Goals of Protection • In one protection model, computer consists of a collection of objects, hardware or software • Each object has a unique name and can be accessed through a well- defined set of operations • Protection problem - ensure that each object is accessed correctly and only by those processes
    [Show full text]
  • Preventing Privilege Escalation
    Preventing Privilege Escalation Niels Provos Markus Friedl Peter Honeyman CITI, University of Michigan GeNUA CITI, University of Michigan Abstract gain extra privilege after successful authentication lim- its the degree of escalation because the user is already Many operating system services require special priv- authorized to hold some privilege. On the other hand, ilege to execute their tasks. A programming error in a a remote adversary gaining superuser privilege with no privileged service opens the door to system compromise authentication presents a greater degree of escalation. in the form of unauthorized acquisition of privileges. In For services that are part of the critical Internet the worst case, a remote attacker may obtain superuser infrastructure is it particularly important to protect privileges. In this paper, we discuss the methodology against programming errors. Sometimes these services and design of privilege separation, a generic approach need to retain special privilege throughout their life- that lets parts of an application run with different levels time. For example, in SSH, the SSH daemon needs to of privilege. Programming errors occurring in the un- know the private host key during re-keying to authenti- privileged parts can no longer be abused to gain unau- cate the key exchange. The daemon also needs to open thorized privileges. Privilege separation is orthogonal new pseudo-terminals when the SSH client so requests. to capability systems or application confinement and These operations require durable special privilege as enhances the security of such systems even further. they can be requested at any time during the lifetime Privilege separation is especially useful for system of a SSH connection.
    [Show full text]
  • OS-Level Attacks and Defenses: from Software to Hardware-Based Exploits © December 2018 by David Gens Phd Referees: Prof
    OS-LEVELATTACKSANDDEFENSES: FROMSOFTWARETOHARDWARE-BASEDEXPLOITS Dissertation zur Erlangung des akademischen Grades Doktor der Ingenieurswissenschaften (Dr.-Ing.) genehmigt durch den Fachbereich Informatik (FB 20) der Technischen Universtität Darmstadt von D AV I D G E N S aus Wiesbaden, Deutschland Gutachter: Prof. Dr.-Ing. Ahmad-Reza Sadeghi (Erstreferent) Prof. Dr. Thorsten Holz (Zweitreferent) Tag der Einreichung: 14. Dezember 2018 Tag der Disputation: 13. Februar 2019 CYSEC/System Security Lab Intel Collaborative Research Institute (ICRI-CARS) Fachbereich für Informatik Technische Universität Darmstadt Hochschulkennziffer: D17 OS-level Attacks and Defenses: from Software to Hardware-based Exploits © December 2018 by David Gens phd referees: Prof. Dr.-Ing. Ahmad-Reza Sadeghi (1st PhD Referee) Prof. Dr. Thorsten Holz (2nd PhD Referee) further phd commission members: Prof. Dr. Sebastian Faust Prof. Dr. Guido Salvaneschi Prof. Dr.-Ing. Thomas Schneider Darmstadt, Germany December 2018 Veröffentlichung unter CC-BY-SA 4.0 International https://creativecommons.org/licenses/ ABSTRACT Run-time attacks have plagued computer systems for more than three decades, with control-flow hijacking attacks such as return-oriented programming repre- senting the long-standing state-of-the-art in memory-corruption based exploits. These attacks exploit memory-corruption vulnerabilities in widely deployed soft- ware, e.g., through malicious inputs, to gain full control over the platform remotely at run time, and many defenses have been proposed and thoroughly studied in the past. Among those defenses, control-flow integrity emerged as a powerful and ef- fective protection against code-reuse attacks in practice. As a result, we now start to see attackers shifting their focus towards novel techniques through a number of increasingly sophisticated attacks that combine software and hardware vulnerabil- ities to construct successful exploits.
    [Show full text]