Attacking dynamic code

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 [Goktas et al. 2014a, Carlini and Wagner 2014, Davi et al. 2014, Goktas 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 Bjorner 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.