Citation Context

... every function return, the program checks the canary against the expected random value and terminates on mismatches. The overheads from the added checks are often negligible (less than 1% on average =-=[61]-=-). Monitoring defenses are the least intrusive form of defense (in many cases, they can be deployed transparently to the program), but are the most vulnerable to detection and deception. Monitoring al...

Citation Context

...on Leakage, Code Diversity, Memory Disclosure, SideChannel Attacks, Address Space Layout Randomization 1. INTRODUCTION Decades of research have gone into solving the problem of memory corruption bugs =-=[39]-=-. These bugs are particularly notorious, as they can often be exploited by a remote attacker to execute arbitrary code on the victim host, effectively compromising that ma∗This work is sponsored by th...

Citation Context

...aims at hiding direct code and data references in instructions, whereas Execute-no-Read (XnR) marks all memory pages (except a sliding window) as non-accessible to prevent memory pages from being dynamically read and disassembled [7]. However, information disclosure is surprisingly hard to prevent. As we explain in Section III, none of these techniques provide sufficient protection against memory disclosure and can be bypassed. They are also not sufficiently practical to protect complex applications such as web browsers that contain justin-time compilers. Finally, we note that Szekeres et al. [62] propose a different approach called Code-Pointer Integrity (CPI) which separates code pointers from non-control data. Kuznetsov et al. [39] implement CPI by placing all code pointers in a secure region which (in 64-bit mode) is hidden by randomizing its offset in the virtual address space. However, Evans et al. [23] successfully bypass this CPI implementation using side-channel attacks enabled by the large size of the secure region. Goals and contributions. In this paper, we focus on code randomization. Our goal is to tackle the shortcomings of existing defenses by closing memory disclosure c...

Citation Context

...ncreased the overhead on SPECint2000 from 21% to 27%. 8.2 Avenues for improvement The traditional shadow stack has close to 10% overhead – which is unlikely to be acceptable for widespread deployment =-=[47]-=- – and even a minimalist parallel shadow stack has roughly 3.5% overhead. However, these were obtained by measuring the overhead of (a) our hand-coded assembly, for (b) a traditional shadow stack, whe...

Citation Context

... vtable hijacking attacks have become one of the most widely used attack vectors recently. Instead of protecting all indirect jumps and inducing a performance impact that prevents widespread adoption =-=[43]-=-, we focus on a specific subset of indirect jumps that are an attractive target for attackers. Recently, several compiler extensions were proposed that protect vtables from hijacking attacks: • GCC in...

Citation Context

...e results, the user can check that the cloud provider did not interfere with the computation. At the same time, the cloud provider can freely schedule and balance the computation between the nodes, as long as all data is eventually processed correctly. The final challenge is to protect the code running in the isolated memory regions from attacks due to unsafe memory accesses. SGX processors allow this code to access the entire address space of its host process, thus unsafe memory accesses can easily leak data or enable other attacks. Since implementing full memory safety for C/C++ [43], [44], [60] is expensive, we instead provide a compiler that efficiently enforces two region self-integrity invariants for code in an isolated region: region-write-integrity which guarantees that writes through pointers write only to address-taken variables or heap allocations in the isolated region, and that indirect call instructions target only address-taken functions in the region; and region-read-write-integrity, which further guarantees that reads through pointers read only from addresses inside the region. Users who want these additional security assurances may use our compiler. We implemented VC3...

Citation Context

...he techniques described in Section 2, there are other related approaches that seek to prevent memory safety errors either directly or indirectly. Please see the recent survey paper by Szekeres et al. =-=[43]-=- for a complete coverage of the efforts in this direction. Hardware support for memory safety. Some hardware proposals, such as Memtracker [44], provide detection of some memory safety violations by m...

Citation Context

... out of its bounds) and temporal safety violations (e.g., referencing through a pointer after the region has been freed). Such violations are a common source of serious security vulnerabilities [12], =-=[81]-=- such as heap-based buffer overflows [1], [5], [33], [72], [76], confidential data leaks [4], and exploitable use-after-free [3], [10], and doublefree bugs [2], [41]. The micro-policy we study here on...