HideM

Abstract

Memory disclosure vulnerabilities have become a common component for enabling reliable exploitation of systems by leaking the contents of executable data. Previous research towards protecting executable data from disclosure has failed to gain popularity due to large performance penalties and required architectural changes. Other research has focused on protecting application data but fails to consider a vulnerable application that leaks its own executable data.In this paper we present HideM, a practical system for protecting against memory disclosures in contemporary commodity systems. HideM addresses limitations in existing advanced security protections (e.g., fine-grained ASLR, CFI) wherein an adversary discloses executable data from memory, reasons about protection weaknesses, and builds corresponding exploits. HideM uses the split-TLB architecture, commonly found in CPUs, to enable fine-grained execute and read permission on memory. HideM enforces finegrained permission based on policy generated from binary structure thus enabling protection of Commercial-Off-TheShelf (COTS) binaries. In our evaluation of HideM, we find application overhead ranges from a 6.5% increase to a 2% reduction in runtime and observe runtime memory overhead ranging from 0.04% to 25%. HideM requires adversaries to guess ROP gadget locations making exploitation unreliable. We find adversaries have less than a 16% chance of correctly guessing a single gadget across all 28 evaluated applications. Thus, HideM is a practical system for protecting vulnerable applications which leak executable data.

CoDaRR: Continuous Data Space Randomization against Data-Only Attacks

“…For data randomization specifically, this means the masks must be protected. In the case of static DSR, where all keys are embedded directly into the protected application's code, one could simply apply an execute-only memory mechanism to protect the keys against disclosure attacks [6,19,24].…”

“…The compiler generates masks for each data partition and embeds them directly in the binary code of the application [8,11], or stores them in a dedicated key cache [7]. In both cases, the masks can be protected from memory exploit-based disclosure, either by giving the binary code pages execute-only permissions [6,19,24], or by modifying the CPU such that the key cache can only be accessed through custom data access instructions [7].…”

CodeArmor: Virtualizing the Code Space to Counter Disclosure Attacks

“…State-of-the-art code disclosure defenses either focus on designing disclosure-resistant diversification techniques [34], [10] or emulating X⊕R semantics [9], [27], [42], [18], [30], [83], [91], [43], [64] to ensure code is executable but not readable. In either cases, such techniques mainly defend against read-based attacks, while leaving generic binaries vulnerable to execution-based attacks.…”

“…In other words, CodeArmor's design probabilistically ensures that only "live" code pointers that can be leaked from data memory can be used (as-is) as individual gadgets by attackers, significantly reducing the attack surface. Unlike existing leakage-resistant code diversification techniques that provide similar security guarantees [43], [42], [27], [30], [83], [91], [64], [10], [9], [18], CodeArmor works entirely at the binary level without any need for source, special hardware support, or modifications to the underlying software stack (i.e., OS or hypervisor).…”

Towards Automated Discovery of Crash-Resistant Primitives in Binary Executables

“…Apart from models that merely restrict an attacker's knowledge of the memory layout, some defenses impose additional properties on the memory. The principle of execute-only memory (XoM) [8], [23] allows for an additional access right, in contrast to the standard of execute access implying read access. Without the possibility of reading the code, an adversary has no way of determining the actual bytes used to implement a given functionality.…”