As human activities have moved to the digital domain, so have all the well-known malicious behaviors including fraud, theft, and other trickery. There is no silver bullet, and each security threat calls for a specific answer. One particular threat is that applications accept malformed inputs, and in many cases it is possible to craft inputs that let an intruder take full control over the target computer system. The nature of systems programming languages lies at the heart of the problem. Rather than rewriting decades of well-tested functionality, this book examines ways to live with the (programming) sins of the past while shoring up security in the most efficient manner possible. We explore a range of different options, each making significant progress toward securing legacy programs from malicious inputs. The solutions explored include enforcement-type defenses, which exclude certain program executions because they never arise during normal operation. Another strand explores the idea of presenting adversaries with a moving target that unpredictably changes its attack surface thanks to randomization. We also cover tandem execution ideas where the compromise of one executing clone causes it to diverge from another, thus revealing adversarial activities.
{"title":"The Continuing Arms Race: Code-Reuse Attacks and Defenses","authors":"Per Larsen, A. Sadeghi","doi":"10.1145/3129743","DOIUrl":"https://doi.org/10.1145/3129743","url":null,"abstract":"As human activities have moved to the digital domain, so have all the well-known malicious behaviors including fraud, theft, and other trickery. There is no silver bullet, and each security threat calls for a specific answer. One particular threat is that applications accept malformed inputs, and in many cases it is possible to craft inputs that let an intruder take full control over the target computer system. \u0000 \u0000The nature of systems programming languages lies at the heart of the problem. Rather than rewriting decades of well-tested functionality, this book examines ways to live with the (programming) sins of the past while shoring up security in the most efficient manner possible. We explore a range of different options, each making significant progress toward securing legacy programs from malicious inputs. \u0000 \u0000The solutions explored include enforcement-type defenses, which exclude certain program executions because they never arise during normal operation. Another strand explores the idea of presenting adversaries with a moving target that unpredictably changes its attack surface thanks to randomization. We also cover tandem execution ideas where the compromise of one executing clone causes it to diverge from another, thus revealing adversarial activities.","PeriodicalId":267501,"journal":{"name":"The Continuing Arms Race","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2018-03-23","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121981183","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Typically, code-reuse attacks exhibit unique characteristics in the control flow (and the data flow) that allow for generic protections, regardless of the language an application was programmed in. For example, if one can afford to monitor all return instructions in an application while maintaining a full shadow call stack, even advanced ROP-based attacks [Göktas et al. 2014a, Carlini and Wagner 2014, Davi et al. 2014, Göktaş et al. 2014b, Schuster et al. 2014] cannot be mounted [Frantzen and Shuey 2001, Abadi et al. 2005a, Davi et al. 2011]. In this chapter, we present a form of code-reuse attack we call Counterfeit Object-Oriented Programming (COOP) that is different: COOP exploits the fact that each C++ virtual function is address taken, which means that a static code pointer exists to it. Accordingly, C++ applications usually contain a high ratio of address-taken functions, typically a significantly higher one compared to C applications. If, for example, an imprecise CFI solution does not consider C++ semantics, then these functions are all likely valid indirect call targets [Abadi et al. 2005a] and can thus be abused. COOP exclusively relies on C++ virtual functions that are invoked through corresponding calling sites as gadgets. Hence, without deeper knowledge of the semantics of an application developed in C++, COOP's control flow cannot reasonably be distinguished from a benign one. Another important difference to existing codereuse attacks is that in COOP conceptually no code pointers (e.g., return addresses or function pointers) are injected or manipulated. As such, COOP is immune to defenses that protect the integrity and authenticity of code pointers. Moreover, in COOP, gadgets do not work relative to the stack pointer. Instead, gadgets are invoked relative to the this-ptr on a set of adversary-defined counterfeit objects. Note that in C++ the this-ptr allows an object to access its own address. Addressing relative to the this-ptr implies that COOP cannot be mitigated by defenses that prevent the stack pointer to point to the program's heap [Fratric 2012], which is typically the case for ROP-based attacks launched through a heap-based memory corruption vulnerability. The counterfeit objects used in a COOP attack typically overlap such that data can be passed from one gadget to another. Even in a simple COOP program, positioning counterfeit objects manually can become complicated. Hence, we implemented a programming framework that leverages the Z3 SMT solver [de Moura and Bjørner 2008] to derive the object layout of a COOP program automatically. The main results of this chapter were published in a previous conference paper [Schuster et al. 2015] and in a Ph.D. dissertation [Schuster 2015]. In this chapter, we streamline the presentation and highlight the challenges when attempting to protect against COOP-like attacks. Certain details are omitted and interested readers are referred to closely related publications on this topic.
通常，代码重用攻击在控制流(和数据流)中表现出允许通用保护的独特特征，而不管应用程序是用什么语言编程的。例如，如果能够在维护完整的影子调用堆栈的同时监控应用程序中的所有返回指令，那么即使是高级基于rop的攻击[Göktas等人，2014a, Carlini和Wagner 2014, Davi等人，2014,Göktaş等人，2014b, Schuster等人，2014]也无法安装[Frantzen和Shuey 2001, Abadi等人，2005a, Davi等人，2011]。在本章中，我们提出了一种不同的代码重用攻击形式，我们称之为伪面向对象编程(COOP): COOP利用了这样一个事实，即每个c++虚函数都是地址占用的，这意味着存在一个指向它的静态代码指针。因此，c++应用程序通常包含高比例的地址占用函数，通常比C应用程序高得多。例如，如果一个不精确的CFI解决方案没有考虑c++语义，那么这些函数都可能是有效的间接调用目标[Abadi等人，2005a]，因此可能被滥用。COOP完全依赖于c++虚函数，虚函数通过相应的调用站点作为gadget调用。因此，如果不深入了解用c++开发的应用程序的语义，就不能合理地将COOP的控制流与良性的控制流区分开来。与现有代码滥用攻击的另一个重要区别是，在COOP中，概念上没有注入或操纵代码指针(例如，返回地址或函数指针)。因此，COOP不受保护代码指针完整性和真实性的防御的影响。此外，在COOP中，gadget并不相对于堆栈指针工作。相反，gadget是相对于一组对手定义的伪造对象上的this-ptr调用的。注意，在c++中this-ptr允许对象访问自己的地址。相对于this-ptr的寻址意味着不能通过防止堆栈指针指向程序堆的防御来缓解COOP，这是通过基于堆的内存损坏漏洞发起的基于rop的攻击的典型情况。COOP攻击中使用的伪造对象通常是重叠的，这样数据就可以从一个设备传递到另一个设备。即使在简单的COOP程序中，手动定位假冒对象也会变得复杂。因此，我们实现了一个编程框架，该框架利用Z3 SMT求解器[de Moura and Bjørner 2008]自动派生出COOP程序的对象布局。本章的主要结果发表在之前的会议论文[Schuster et al. 2015]和博士论文[Schuster 2015]中。在本章中，我们简化了演示，并强调了在尝试防范类似coop的攻击时所面临的挑战。某些细节被省略，感兴趣的读者可以参考与此主题密切相关的出版物。
{"title":"Attacking dynamic code","authors":"Felix Schuster, Thorsten Holz","doi":"10.1145/3129743.3129750","DOIUrl":"https://doi.org/10.1145/3129743.3129750","url":null,"abstract":"Typically, code-reuse attacks exhibit unique characteristics in the control flow (and the data flow) that allow for generic protections, regardless of the language an application was programmed in. For example, if one can afford to monitor all return instructions in an application while maintaining a full shadow call stack, even advanced ROP-based attacks [Göktas et al. 2014a, Carlini and Wagner 2014, Davi et al. 2014, Göktaş et al. 2014b, Schuster et al. 2014] cannot be mounted [Frantzen and Shuey 2001, Abadi et al. 2005a, Davi et al. 2011]. In this chapter, we present a form of code-reuse attack we call Counterfeit Object-Oriented Programming (COOP) that is different: COOP exploits the fact that each C++ virtual function is address taken, which means that a static code pointer exists to it. Accordingly, C++ applications usually contain a high ratio of address-taken functions, typically a significantly higher one compared to C applications. If, for example, an imprecise CFI solution does not consider C++ semantics, then these functions are all likely valid indirect call targets [Abadi et al. 2005a] and can thus be abused. COOP exclusively relies on C++ virtual functions that are invoked through corresponding calling sites as gadgets. Hence, without deeper knowledge of the semantics of an application developed in C++, COOP's control flow cannot reasonably be distinguished from a benign one. Another important difference to existing codereuse attacks is that in COOP conceptually no code pointers (e.g., return addresses or function pointers) are injected or manipulated. As such, COOP is immune to defenses that protect the integrity and authenticity of code pointers. Moreover, in COOP, gadgets do not work relative to the stack pointer. Instead, gadgets are invoked relative to the this-ptr on a set of adversary-defined counterfeit objects. Note that in C++ the this-ptr allows an object to access its own address. Addressing relative to the this-ptr implies that COOP cannot be mitigated by defenses that prevent the stack pointer to point to the program's heap [Fratric 2012], which is typically the case for ROP-based attacks launched through a heap-based memory corruption vulnerability. The counterfeit objects used in a COOP attack typically overlap such that data can be passed from one gadget to another. Even in a simple COOP program, positioning counterfeit objects manually can become complicated. Hence, we implemented a programming framework that leverages the Z3 SMT solver [de Moura and Bjørner 2008] to derive the object layout of a COOP program automatically. The main results of this chapter were published in a previous conference paper [Schuster et al. 2015] and in a Ph.D. dissertation [Schuster 2015]. In this chapter, we streamline the presentation and highlight the challenges when attempting to protect against COOP-like attacks. Certain details are omitted and interested readers are referred to closely related publications on this topic.","PeriodicalId":267501,"journal":{"name":"The Continuing Arms Race","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2018-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124670987","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
One important aspect of making Control-Flow Integrity (CFI) practical is to support modularity. In the context of CFI, modularity refers to the ability to perform instrumentation of modules of an application separately, without considering other modules, and to link instrumented modules into an executable on demand. Modularity support is of crucial importance for accommodating dynamic linking, which loads libraries at runtime and is frequently used in modern software systems since it allows different software vendors to work on or update modules independently. Just-In-Time (JIT) compilation also requires modularity support because a piece of newly generated code by a JIT compiler can be considered a module, which is to be "linked" with the JIT compiler. In both dynamic linking and JIT compilation, not all code is available statically. The code of a dynamically linked library is available only after the library has been loaded at runtime, which may happen during the middle of a program execution; in JIT compilation, the binary code of a function is available only after the function has been compiled on the fly. We call this kind of code dynamic code since it is available only after a runtime event. Unfortunately, many CFI systems require all modules of an application, including libraries, to be available at the static instrumentation time. They perform a global analysis on all code to construct a global Control-Flow Graph (CFG). Instrumentation schemes in many CFI systems also assume global code properties. For instance, instrumentation in the classic CFI [Abadi et al. 2005a] inserts identifiers (representing a class of indirect branches and targets) before branch targets and inserts checks before indirect branches to make sure the right identifiers according to the CFG are at the targets. The identifiers are embedded as instructions in code and cannot appear in the rest of the code. However, this property cannot be guaranteed without inspecting the whole program. Many other CFI instrumentation techniques also do not support modularity; the reasons for this are discussed in Section 2.5. In this chapter, we present a modular CFI system that extends CFI to support dynamic code.We start with an overview of the main challenges and solutions when dealing with dynamic code in Section 2.1. In Section 2.2, we present a compilerassisted, type-based scheme that allows efficient CFG construction in the presence of dynamic code. In Section 2.3, we present a modular CFI system that supports dynamic libraries by adopting the type-based CFG construction process and a technique for supporting multi-threading. In Section 2.4, we show that, with some adjustments, the modular CFI system can support JIT compilation. We discuss related work in Section 2.5 and conclude in Section 2.6. The main results of this chapter were published in previous conference papers [Niu and Tan 2014a, Niu and Tan 2014b] and in a Ph.D. dissertation [Niu 2015]. In this chapter, we streamline
实现控制流完整性(CFI)的一个重要方面是支持模块化。在CFI的上下文中，模块化指的是在不考虑其他模块的情况下单独执行应用程序模块的插装，并将插装的模块按需链接到可执行文件中的能力。模块化支持对于适应动态链接至关重要，动态链接在运行时加载库，并且在现代软件系统中经常使用，因为它允许不同的软件供应商独立地处理或更新模块。即时(JIT)编译还需要模块化支持，因为JIT编译器新生成的一段代码可以被视为一个模块，该模块将与JIT编译器“链接”。在动态链接和JIT编译中，并非所有代码都是静态可用的。动态链接库的代码只有在运行时加载库之后才可用，这可能发生在程序执行的中间;在JIT编译中，函数的二进制代码只有在该函数被动态编译之后才可用。我们称这种代码为动态代码，因为它仅在运行时事件之后可用。不幸的是，许多CFI系统要求应用程序的所有模块(包括库)在静态检测时可用。他们对所有代码执行全局分析，以构建全局控制流图(CFG)。许多CFI系统中的检测方案也假定了全局代码属性。例如，经典CFI中的检测[Abadi等人，2005a]在分支目标之前插入标识符(代表一类间接分支和目标)，并在间接分支之前插入检查，以确保根据CFG的正确标识符位于目标处。标识符作为指令嵌入到代码中，不能出现在代码的其余部分中。但是，如果不检查整个程序，则无法保证此属性。许多其他CFI仪器技术也不支持模块化;原因将在2.5节中讨论。在本章中，我们提出了一个模块化的CFI系统，扩展了CFI以支持动态代码。我们首先概述2.1节中处理动态代码时的主要挑战和解决方案。在第2.2节中，我们提出了一个编译器辅助的、基于类型的方案，该方案允许在动态代码存在的情况下高效地构建CFG。在2.3节中，我们提出了一个模块化的CFI系统，该系统通过采用基于类型的CFG构建过程和支持多线程的技术来支持动态库。在第2.4节中，我们将展示，通过一些调整，模块化的CFI系统可以支持JIT编译。我们将在2.5节讨论相关工作，并在2.6节结束。本章的主要成果发表在之前的会议论文[Niu and Tan 2014a, Niu and Tan 2014b]和博士论文[Niu 2015]中。在本章中，我们通过整合以前的论文并突出未来CFI研究感兴趣的最重要的思想和信息来简化演示。某些细节被省略，感兴趣的读者可以参考以前的论文。此外，本章中包含的实验结果可能与会议出版物中的结果不同，因为我们在会议出版物发表后进行了改进。
{"title":"Protecting dynamic code","authors":"Gang Tan, Ben Niu","doi":"10.1145/3129743.3129746","DOIUrl":"https://doi.org/10.1145/3129743.3129746","url":null,"abstract":"One important aspect of making Control-Flow Integrity (CFI) practical is to support modularity. In the context of CFI, modularity refers to the ability to perform instrumentation of modules of an application separately, without considering other modules, and to link instrumented modules into an executable on demand. Modularity support is of crucial importance for accommodating dynamic linking, which loads libraries at runtime and is frequently used in modern software systems since it allows different software vendors to work on or update modules independently. Just-In-Time (JIT) compilation also requires modularity support because a piece of newly generated code by a JIT compiler can be considered a module, which is to be \"linked\" with the JIT compiler. In both dynamic linking and JIT compilation, not all code is available statically. The code of a dynamically linked library is available only after the library has been loaded at runtime, which may happen during the middle of a program execution; in JIT compilation, the binary code of a function is available only after the function has been compiled on the fly. We call this kind of code dynamic code since it is available only after a runtime event. Unfortunately, many CFI systems require all modules of an application, including libraries, to be available at the static instrumentation time. They perform a global analysis on all code to construct a global Control-Flow Graph (CFG). Instrumentation schemes in many CFI systems also assume global code properties. For instance, instrumentation in the classic CFI [Abadi et al. 2005a] inserts identifiers (representing a class of indirect branches and targets) before branch targets and inserts checks before indirect branches to make sure the right identifiers according to the CFG are at the targets. The identifiers are embedded as instructions in code and cannot appear in the rest of the code. However, this property cannot be guaranteed without inspecting the whole program. Many other CFI instrumentation techniques also do not support modularity; the reasons for this are discussed in Section 2.5. In this chapter, we present a modular CFI system that extends CFI to support dynamic code.We start with an overview of the main challenges and solutions when dealing with dynamic code in Section 2.1. In Section 2.2, we present a compilerassisted, type-based scheme that allows efficient CFG construction in the presence of dynamic code. In Section 2.3, we present a modular CFI system that supports dynamic libraries by adopting the type-based CFG construction process and a technique for supporting multi-threading. In Section 2.4, we show that, with some adjustments, the modular CFI system can support JIT compilation. We discuss related work in Section 2.5 and conclude in Section 2.6. The main results of this chapter were published in previous conference papers [Niu and Tan 2014a, Niu and Tan 2014b] and in a Ph.D. dissertation [Niu 2015]. In this chapter, we streamline","PeriodicalId":267501,"journal":{"name":"The Continuing Arms Race","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2018-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132964824","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Memory corruption vulnerabilities are a common problem in software implemented in C/C++. Attackers can exploit these vulnerabilities to steal sensitive data and to seize or disrupt the system on which the software is executed. Memory safety techniques can, in principle, eliminate these vulnerabilities [Nagarakatte et al. 2009, Nagarakatte et al. 2010] but are prohibitively expensive in terms of runtime overhead [Szekeres et al. 2013]. Instead, modern operating systems and compilers deploy exploit mitigations such as Address Space Layout Randomization (ASLR) [PaX Team 2004a], Data Execution Prevention (DEP, a.k.a.W.X) [PaX Team 2004b], and stack canaries [Cowan et al. 1998]. These exploit mitigations incur minimal performance overhead, but are limited in scope.often only defending against one particular type of exploit.and can be bypassed with only modest effort. Up-and-coming exploit mitigations, such as control-flow integrity [Abadi et al. 2005a, Tice et al. 2014], require more effort to bypass [Göktas et al. 2014a, Davi et al. 2014, Carlini et al. 2015e, Evans et al. 2015, Schuster et al. 2015], but, similar to the aforementioned defenses, they defend only against attacks of one particular type: code reuse. The ubiquity of multi-core processors has made Multi-Variant Execution Environments (MVEEs) an increasingly attractive option to provide strong, comprehensive protection against memory corruption exploits, while still incurring only a fraction of the runtime overhead of full memory safety. MVEEs have been shown to successfully defend against several types of attacks, including code reuse [Volckaert et al. 2015], information leakage [Koning et al. 2016], stack buffer overflows [Salamat et al. 2009], and code injection [Cox et al. 2006]. The underlying idea is to run several diversified instances of the same program, often referred to as variants or replicas, side by side on equivalent program inputs. The MVEE's main component, the monitor, feeds all variants these equivalent inputs and monitors the variants' behavior. The diversity techniques used to generate the variants ensure that the variants respond differently to malicious inputs, while leaving the behavior under normal operating conditions unaffected. The MVEE monitor detects the diverging behavior and halts the execution of the variants before they can harm the system. This implies that the variants must, to some extent, be executed in lockstep: potentially harmful operations in a variant are only executed when the consistency with the other variants has been validated. In recent years, over half a dozen systems have been proposed that match the above description. While most of them show many similarities, some authors have made radically different design choices. In this chapter, we discuss the design of MVEEs and provide implementation details about our own MVEE, the Ghent University Multi-Variant Execution Environment, orGHUMVEE, and its extensions. GHUMVEEhas been open sourced and
在用C/ c++实现的软件中，内存损坏漏洞是一个常见的问题。攻击者可以利用这些漏洞窃取敏感数据，并夺取或破坏执行软件的系统。内存安全技术原则上可以消除这些漏洞[Nagarakatte et al. 2009, Nagarakatte et al. 2010]，但就运行时开销而言，它们的成本过高[Szekeres et al. 2013]。相反，现代操作系统和编译器部署了一些漏洞缓解措施，如地址空间布局随机化(ASLR) [PaX Team 2004a]、数据执行预防(DEP, a.a.w.x) [PaX Team 2004b]和堆栈金丝猴[Cowan等人，1998]。这些利用缓解会产生最小的性能开销，但范围有限。通常只防御一种特定类型的攻击。只要稍加努力就能绕过它。即将出现的漏洞缓解措施，如控制流完整性[Abadi等人，2005a, Tice等人，2014]，需要更多的努力来绕过[Göktas等人，2014a, Davi等人，2014,Carlini等人，2015e, Evans等人，2015,Schuster等人，2015]，但是，与上述防御类似，它们只防御一种特定类型的攻击:代码重用。多核处理器的普及使得多变体执行环境(Multi-Variant Execution Environments, mvee)成为一种越来越有吸引力的选择，它可以提供强大、全面的保护，防止内存破坏，同时只产生完全内存安全的一小部分运行时开销。mvee已被证明能够成功抵御多种类型的攻击，包括代码重用[Volckaert等人，2015]、信息泄漏[Koning等人，2016]、堆栈缓冲区溢出[Salamat等人，2009]和代码注入[Cox等人，2006]。其基本思想是在相同的程序输入上并行运行同一程序的多个不同实例(通常称为变体或副本)。MVEE的主要组件是监视器，它为所有变体提供这些等效输入，并监视变体的行为。用于生成变体的多样性技术确保变体对恶意输入的响应不同，同时使正常操作条件下的行为不受影响。MVEE监控器可以检测到偏离行为，并在变体破坏系统之前停止执行。这意味着，在某种程度上，变体必须同步执行:只有在验证了变体与其他变体的一致性后，才会执行变体中可能有害的操作。近年来，已经提出了超过六种符合上述描述的系统。虽然他们中的大多数显示出许多相似之处，但有些作者做出了截然不同的设计选择。在本章中，我们讨论了MVEE的设计，并提供了我们自己的MVEE的实现细节，根特大学多变量执行环境，orGHUMVEE，及其扩展。ghumvee已经开源，可以从http://github.com/ stijn-volckaert/ReMon/下载。
{"title":"Multi-variant execution environments","authors":"Bart Coppens, B. D. Sutter, Stijn Volckaert","doi":"10.1145/3129743.3129752","DOIUrl":"https://doi.org/10.1145/3129743.3129752","url":null,"abstract":"Memory corruption vulnerabilities are a common problem in software implemented in C/C++. Attackers can exploit these vulnerabilities to steal sensitive data and to seize or disrupt the system on which the software is executed. Memory safety techniques can, in principle, eliminate these vulnerabilities [Nagarakatte et al. 2009, Nagarakatte et al. 2010] but are prohibitively expensive in terms of runtime overhead [Szekeres et al. 2013]. Instead, modern operating systems and compilers deploy exploit mitigations such as Address Space Layout Randomization (ASLR) [PaX Team 2004a], Data Execution Prevention (DEP, a.k.a.W.X) [PaX Team 2004b], and stack canaries [Cowan et al. 1998]. These exploit mitigations incur minimal performance overhead, but are limited in scope.often only defending against one particular type of exploit.and can be bypassed with only modest effort. Up-and-coming exploit mitigations, such as control-flow integrity [Abadi et al. 2005a, Tice et al. 2014], require more effort to bypass [Göktas et al. 2014a, Davi et al. 2014, Carlini et al. 2015e, Evans et al. 2015, Schuster et al. 2015], but, similar to the aforementioned defenses, they defend only against attacks of one particular type: code reuse. The ubiquity of multi-core processors has made Multi-Variant Execution Environments (MVEEs) an increasingly attractive option to provide strong, comprehensive protection against memory corruption exploits, while still incurring only a fraction of the runtime overhead of full memory safety. MVEEs have been shown to successfully defend against several types of attacks, including code reuse [Volckaert et al. 2015], information leakage [Koning et al. 2016], stack buffer overflows [Salamat et al. 2009], and code injection [Cox et al. 2006]. The underlying idea is to run several diversified instances of the same program, often referred to as variants or replicas, side by side on equivalent program inputs. The MVEE's main component, the monitor, feeds all variants these equivalent inputs and monitors the variants' behavior. The diversity techniques used to generate the variants ensure that the variants respond differently to malicious inputs, while leaving the behavior under normal operating conditions unaffected. The MVEE monitor detects the diverging behavior and halts the execution of the variants before they can harm the system. This implies that the variants must, to some extent, be executed in lockstep: potentially harmful operations in a variant are only executed when the consistency with the other variants has been validated. In recent years, over half a dozen systems have been proposed that match the above description. While most of them show many similarities, some authors have made radically different design choices. In this chapter, we discuss the design of MVEEs and provide implementation details about our own MVEE, the Ghent University Multi-Variant Execution Environment, orGHUMVEE, and its extensions. GHUMVEEhas been open sourced and","PeriodicalId":267501,"journal":{"name":"The Continuing Arms Race","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2018-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121307234","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Stephen Crane, Andrei Homescu, Per Larsen, Hamed Okhravi, M. Franz
Almost three decades ago, the Morris Worm infected thousands of UNIX workstations by, among other things, exploiting a buffer-overflow error in the fingerd daemon [Spafford 1989]. Buffer overflows are just one example of a larger class of memory (corruption) errors [Szekeres et al. 2013, van der Veen et al. 2012]. The root of the issue is that systems programming languages---C and its derivatives---expect programmers to access memory correctly and eschew runtime safety checks to maximize performance. There are three possible ways to address the security issues associated with memory corruption. One is to migrate away from these legacy languages that were designed four decades ago, long before computers were networked and thus exposed to remote adversaries. Another is to retrofit the legacy code with runtime safety checks. This is a great option whenever the, often substantial, cost of runtime checking is acceptable. In cases where legacy code must run at approximately the same speed, however, we must fall back to targeted mitigations, which, unlike the other remedies, do not prevent memory corruption. Instead, mitigations make it harder, i.e., more labor intensive, to turn errors into exploits. Since stack-based buffer overwrites were the basis of the first exploits, the first mitigations were focused on preventing the corresponding stack smashing exploits [Levy 1996]. The first mitigations worked by placing a canary, i.e., a random value checked before function returns, between the return address and any buffers that could overflow [Cowan et al. 1998]. Another countermeasure that is now ubiquitous makes the stack non-executable. Since then, numerous other countermeasures have appeared and the most efficient of those have made it into practice [Meer 2010]. While the common goal of countermeasures is to stop exploitation of memory corruption, their mechanisms differ widely. Generally speaking, countermeasures rely on randomization, enforcement, isolation, or a combination thereof. Address space layout randomization is the canonical example of a purely randomization-based technique. Control-Flow Integrity (CFI [Abadi et al. 2005a, Burow et al. 2016]) is a good example of an enforcement technique. Software-fault isolation, as the name implies, is a good example of an isolation scheme. Code- Pointer Integrity (CPI [Kuznetsov et al. 2014a]) is an isolation scheme focused on code pointers. While the rest of this chapter focuses on randomization-based mitigations, we stress that the best way to mitigate memory corruption vulnerabilities is to deploy multiple different mitigation techniques, as opposed to being overly reliant on any single defense.
大约三十年前，Morris蠕虫通过利用fingerd守护进程中的缓冲区溢出错误感染了数千台UNIX工作站[Spafford 1989]。缓冲区溢出只是更大类内存(损坏)错误的一个例子[Szekeres et al. 2013, van der Veen et al. 2012]。问题的根源在于，系统编程语言——C及其衍生语言——希望程序员正确访问内存，并避免运行时安全检查，以最大限度地提高性能。有三种可能的方法来解决与内存损坏相关的安全问题。一种是远离这些40年前设计的遗留语言，早在计算机联网之前，因此暴露给远程对手。另一种方法是用运行时安全检查改造遗留代码。只要运行时检查的成本(通常是可观的)是可以接受的，这就是一个很好的选择。然而，在遗留代码必须以大致相同的速度运行的情况下，我们必须退回到有针对性的缓解措施，这与其他补救措施不同，它不能防止内存损坏。相反，缓解使将错误转化为攻击变得更加困难，也就是说，需要更多的劳动。由于基于堆栈的缓冲区覆盖是第一次漏洞利用的基础，因此第一次缓解的重点是防止相应的堆栈破坏漏洞利用[Levy 1996]。第一种缓解方法是在返回地址和可能溢出的缓冲区之间放置一个金丝雀，即在函数返回之前检查一个随机值[Cowan et al. 1998]。现在普遍存在的另一种对策是使堆栈不可执行。从那时起，出现了许多其他对策，其中最有效的对策已付诸实践[Meer 2010]。虽然对策的共同目标是阻止利用内存损坏，但它们的机制差别很大。一般来说，对策依赖于随机化、强制、隔离或它们的组合。地址空间布局随机化是纯粹基于随机化技术的典型例子。控制流完整性(CFI [Abadi et al. 2005a, Burow et al. 2016])是执行技术的一个很好的例子。软件故障隔离，顾名思义，是隔离方案的一个很好的例子。代码指针完整性(CPI [Kuznetsov et al. 2014a])是一种专注于代码指针的隔离方案。虽然本章的其余部分主要关注基于随机化的缓解，但我们强调缓解内存损坏漏洞的最佳方法是部署多种不同的缓解技术，而不是过度依赖任何一种防御。
{"title":"Diversity and information leaks","authors":"Stephen Crane, Andrei Homescu, Per Larsen, Hamed Okhravi, M. Franz","doi":"10.1145/3129743.3129747","DOIUrl":"https://doi.org/10.1145/3129743.3129747","url":null,"abstract":"Almost three decades ago, the Morris Worm infected thousands of UNIX workstations by, among other things, exploiting a buffer-overflow error in the fingerd daemon [Spafford 1989]. Buffer overflows are just one example of a larger class of memory (corruption) errors [Szekeres et al. 2013, van der Veen et al. 2012]. The root of the issue is that systems programming languages---C and its derivatives---expect programmers to access memory correctly and eschew runtime safety checks to maximize performance. There are three possible ways to address the security issues associated with memory corruption. One is to migrate away from these legacy languages that were designed four decades ago, long before computers were networked and thus exposed to remote adversaries. Another is to retrofit the legacy code with runtime safety checks. This is a great option whenever the, often substantial, cost of runtime checking is acceptable. In cases where legacy code must run at approximately the same speed, however, we must fall back to targeted mitigations, which, unlike the other remedies, do not prevent memory corruption. Instead, mitigations make it harder, i.e., more labor intensive, to turn errors into exploits. Since stack-based buffer overwrites were the basis of the first exploits, the first mitigations were focused on preventing the corresponding stack smashing exploits [Levy 1996]. The first mitigations worked by placing a canary, i.e., a random value checked before function returns, between the return address and any buffers that could overflow [Cowan et al. 1998]. Another countermeasure that is now ubiquitous makes the stack non-executable. Since then, numerous other countermeasures have appeared and the most efficient of those have made it into practice [Meer 2010]. While the common goal of countermeasures is to stop exploitation of memory corruption, their mechanisms differ widely. Generally speaking, countermeasures rely on randomization, enforcement, isolation, or a combination thereof. Address space layout randomization is the canonical example of a purely randomization-based technique. Control-Flow Integrity (CFI [Abadi et al. 2005a, Burow et al. 2016]) is a good example of an enforcement technique. Software-fault isolation, as the name implies, is a good example of an isolation scheme. Code- Pointer Integrity (CPI [Kuznetsov et al. 2014a]) is an isolation scheme focused on code pointers. While the rest of this chapter focuses on randomization-based mitigations, we stress that the best way to mitigate memory corruption vulnerabilities is to deploy multiple different mitigation techniques, as opposed to being overly reliant on any single defense.","PeriodicalId":267501,"journal":{"name":"The Continuing Arms Race","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2018-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122946364","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Enes Göktas, E. Athanasopoulos, H. Bos, G. Portokalidis
{"title":"Evaluating control-flow restricting defenses","authors":"Enes Göktas, E. Athanasopoulos, H. Bos, G. Portokalidis","doi":"10.1145/3129743.3129749","DOIUrl":"https://doi.org/10.1145/3129743.3129749","url":null,"abstract":"","PeriodicalId":267501,"journal":{"name":"The Continuing Arms Race","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2018-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126658715","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Yier Jin, Dean Sullivan, Orlando Arias, A. Sadeghi, Lucas Davi
Control-Flow Integrity (CFI) is a promising and general defense against control-flow hijacking with formal underpinnings. A key insight from the extensive research on CFI is that its effectiveness depends on the precision and coverage of a program's Control-Flow Graph (CFG). Since precise CFG generation is highly challenging and often difficult, many CFI schemes rely on brittle heuristics and imprecise, coarse-grained CFGs. Furthermore, comprehensive, fine-grained CFI defenses implemented purely in software incur overheads that are unacceptably high. In this chapter, we first specify a CFI model that captures many known CFI techniques, including stateless and stateful approaches as well as fine-grained and coarse-grained CFI policies.We then design and implement a novel hardwareenhanced CFI. Key to this approach is a set of dedicated CFI instructions that can losslessly enforce any CFG and diverse CFI policies within our model. Moreover, we fully support multi-tasking and shared libraries, prevent various forms of codereuse attacks, and allow code protected with CFI to interoperate with unprotected legacy code. Our prototype implementation on the SPARC LEON3 is highly efficient with a performance overhead of 1.75% on average when applied to several SPECInt2006 benchmarks and 0.5% when applied to EEMBC's CoreMark benchmark.
{"title":"Hardware control flow integrity","authors":"Yier Jin, Dean Sullivan, Orlando Arias, A. Sadeghi, Lucas Davi","doi":"10.1145/3129743.3129751","DOIUrl":"https://doi.org/10.1145/3129743.3129751","url":null,"abstract":"Control-Flow Integrity (CFI) is a promising and general defense against control-flow hijacking with formal underpinnings. A key insight from the extensive research on CFI is that its effectiveness depends on the precision and coverage of a program's Control-Flow Graph (CFG). Since precise CFG generation is highly challenging and often difficult, many CFI schemes rely on brittle heuristics and imprecise, coarse-grained CFGs. Furthermore, comprehensive, fine-grained CFI defenses implemented purely in software incur overheads that are unacceptably high. In this chapter, we first specify a CFI model that captures many known CFI techniques, including stateless and stateful approaches as well as fine-grained and coarse-grained CFI policies.We then design and implement a novel hardwareenhanced CFI. Key to this approach is a set of dedicated CFI instructions that can losslessly enforce any CFG and diverse CFI policies within our model. Moreover, we fully support multi-tasking and shared libraries, prevent various forms of codereuse attacks, and allow code protected with CFI to interoperate with unprotected legacy code. Our prototype implementation on the SPARC LEON3 is highly efficient with a performance overhead of 1.75% on average when applied to several SPECInt2006 benchmarks and 0.5% when applied to EEMBC's CoreMark benchmark.","PeriodicalId":267501,"journal":{"name":"The Continuing Arms Race","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2018-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123873586","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Volodymyr Kuznetsov, László Szekeres, Mathias Payer, George Candea, R. Sekar, D. Song
In this chapter, we describe code-pointer integrity (CPI), a new design point that guarantees the integrity of all code pointers in a program (e.g., function pointers, saved return addresses) and thereby prevents all control-flow hijack attacks that exploit memory corruption errors, including attacks that bypass control-flow integrity mechanisms, such as control-flow bending [Carlini et al. 2015e]. We also describe code-pointer separation (CPS), a relaxation of CPI with better performance properties. CPI and CPS offer substantially better security-to-overhead ratios than the state of the art, and they are practical (CPI and CPS were used to protect a complete FreeBSD system and over 100 packages like apache and postgresql), effective (prevented all attacks in the RIPE benchmark), and efficient: on SPEC CPU2006, CPS averages 1.2% overhead for C and 1.9% for C/C++, while CPI's overhead is 2.9% for C and 8.4% for C/C++. This chapter is organized as follows: we introduce the motivation and key ideas behind CPI and CPS (Section 4.1), describe related work (Section 4.2), introduce our threat model (Section 4.3), describe CPI and CPS design (Section 4.4), present the formal model of CPI (Section 4.5), describe an implementation of CPI (Section 4.6) and the experimental results (Section 4.7), and then conclude (Section 4.8).
{"title":"Code-pointer integrity","authors":"Volodymyr Kuznetsov, László Szekeres, Mathias Payer, George Candea, R. Sekar, D. Song","doi":"10.1145/3129743.3129748","DOIUrl":"https://doi.org/10.1145/3129743.3129748","url":null,"abstract":"In this chapter, we describe code-pointer integrity (CPI), a new design point that guarantees the integrity of all code pointers in a program (e.g., function pointers, saved return addresses) and thereby prevents all control-flow hijack attacks that exploit memory corruption errors, including attacks that bypass control-flow integrity mechanisms, such as control-flow bending [Carlini et al. 2015e]. We also describe code-pointer separation (CPS), a relaxation of CPI with better performance properties. CPI and CPS offer substantially better security-to-overhead ratios than the state of the art, and they are practical (CPI and CPS were used to protect a complete FreeBSD system and over 100 packages like apache and postgresql), effective (prevented all attacks in the RIPE benchmark), and efficient: on SPEC CPU2006, CPS averages 1.2% overhead for C and 1.9% for C/C++, while CPI's overhead is 2.9% for C and 8.4% for C/C++. This chapter is organized as follows: we introduce the motivation and key ideas behind CPI and CPS (Section 4.1), describe related work (Section 4.2), introduce our threat model (Section 4.3), describe CPI and CPS design (Section 4.4), present the formal model of CPI (Section 4.5), describe an implementation of CPI (Section 4.6) and the experimental results (Section 4.7), and then conclude (Section 4.8).","PeriodicalId":267501,"journal":{"name":"The Continuing Arms Race","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2014-10-06","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115007527","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：