Strict Virtual Call Integrity Checking for C++ Binaries

Abstract

Modern operating systems are equipped with defenses that render legacy code injection attacks inoperable. However, attackers can bypass these defenses by crafting attacks that reuse existing code in a program's memory. One of the most common classes of attacks manipulates memory data used indirectly to execute code, such as function pointers. This is especially prevalent in C ++ programs, since tables of function pointers (vtables) are used by all major compilers to support polymorphism. In this paper, we propose VCI, a binary rewriting system that secures C ++ binaries against vtable attacks. VCI works directly on stripped binary files. It identifies and reconstructs various C ++ semantics from the binary, and constructs a strict CFI policy by resolving and pairing virtual function calls (vcalls) with precise sets of target classes. The policy is enforced by instrumenting checks into the binary at vcall sites. Experimental results on SPEC CPU2006 and Firefox show that VCI is significantly more precise than state-of-the-art binary solutions. Testing against the ground truth from the source-based defense GCC VTV, VCI achieved greater than 60% precision in most cases, accounting for at least 48% to 99% additional reduction in the attack surface compared to the state-ofthe-art binary defenses. VCI incurs a 7.79% average runtime overhead which is comparable to the state-of-the-art. In addition, we discuss how VCI defends against real-world attacks, and how it impacts advanced vtable reuse attacks such as COOP.

SAVI objects: sharing and virtuality incorporated

“…A lot of work has been done on security implications of how dynamic dispatch is implemented [Borchert and Spinczyk 2016;Bounov et al 2016;Dewey and Giffin 2012;Elsabagh et al 2017;Gawlik and Holz 2014;Haller et al 2015;Jang et al 2014;Miller et al 2014;Prakash et al 2015;Sarbinowski et al 2016;Tice et al 2014;Zhang et al , 2016Zixiang et al 2016]. Our work is concerned with object sharing, but security implications would be interesting to study.…”

VPS

“…Most existing vtable hijacking defenses assign a set of allowed target functions to each virtual callsite (e.g., Marx VTable Protection [34], vfGuard [36], T-VIP [24], VTint [44] and VCI [22]). The inaccuracy of binary analysis forces them to overestimate the target set, leaving room for attacks [39].…”

“…Meanwhile, handles all previously verified callsite with high optimized fast checks. This approach allows us to prevent false positives from breaking the application as they do in existing work [22,24,36,44]. Additionally, while existing work [27][28][29]34] only considers directly referenced vtables, compilers also generate code that references vtables indirectly, e.g., through the Global Offset Table (GOT).…”

Advanced code reuse attacks against modern defences

“…They proposed a vtable protection policy based on the resolved class hierarchy. Then, Elsabagh et al proposed VCI[72], combining Marx and vfGuard, to instrument before the identified virtual callsite to limit the valid targets. Both techniques try to recover the class hierarchy and layout relation from constructor functions.…”

“…In addition, in the PoC exploits on Flash Player and Internet Explorer, we trigger LOOP attacks from Object.toString by overwriting the vtable pointer of Object. At the vulnerable callsite, we apply the same backward analysis as described in VCI, and verify that the type information cannot be resolved.In the evaluation of VCI on libxul.so[72], the class type information can be fully resolved for 32% of the identified virtual callsites. In the evaluation of Marx[101], the resolved class type information at the virtual callsites does not exceed 20% of the total number of virtual callsites.…”