Citation Context

...ns to change the memory area of a code pointer) [2, 22, 28, 29], (iii) randomizing the location of code regions or code blocks (ASLR or code diversification are examples of probabilistic protections) =-=[11,18,23,35]-=-, or (iv) verifying the correctness of code pointers when they are used, e.g., Control-Flow Integrity (CFI) [1]. CFI does not prevent memory corruption but detects corrupted values when they are used ...

Citation Context

...sic blocks could potentially lead to poor locality and substantial performance loss. Remix instead shuffles basic blocks locally. It can also bundle closely-related basic blocks together (e.g., tight loops) to further reduce the performance overhead. Simplicity and efficiency are two major advantages of Remix. They make Remix an ideal technique to compose with other defenses. For example, Remix should be used with ASLR so that functions are randomized at least once (during program startup). Other examples of compatible techniques include defenses against JIT-ROP [47] or Blind-ROP [10] attacks [6, 19, 26] and function-level re-randomization [27]. Remix can significantly increase the unpredictability of those systems 0x400d30: pushq %rbp 0x400d31: movq %rsp, %rbp ...... 0x400d44: jle 0x400d70 0x400d4a: nopl 8(%rax, %rax) 0x400d4f: leaq 0xd77e(%rip), %rdi ...... 0x400d58: callq 0x400ae0 ...... 0x400d66: jmpq 0x400d7c 0x400d6b: nopl 8(%rax, %rax) 0x400d70: movl $0, -4(%rbp) 0x400d77: nopl 8(%rax, %rax) 0x400d7c: movl -4(%rbp), %eax ...... 0x400d83: popq %rbp 0x400d84: retq 0x400d85: nopl 8(%rax, %rax) 0x400d30: jmpq 0x400d5f 0x400d35: leaq 0xd798(%rip), %rdi ...... 0x400d3e: callq 0x400ae0 .........

Citation Context

... mitigation against ROP attacks. To counter this new threat, researchers have revived the idea of execute-only memory (XOM) [24]. This approach involves preventing programs from reading executable memory using general purpose memory access instructions. One challenge in realizing these systems is that legacy binaries and compilers often intersperse code and data (e.g. jump tables) in executable memory pages. Thus, the wholesale blinding of executable memory at page granularity is not an option. To tackle this issue, researchers have used static compilation techniques to separate code and data [5]. However, this solution does not work well in the absence of source code, for instance, when utilizing legacy binaries. In fact, separating data from code has been shown to be provably undecidable [28]. Another complication in realizing the XOM concept arises from web browsers’ use of JIT code where data becomes dynamically generated code. This has been shown to be a significant attack surface for browsers [1, 29]. In this work, we propose a new concept to deal with memory disclosure attacks. Unlike XOM and XOM-inspired systems, which aim to completely prevent reads to executable memory, a ta...

Citation Context

...a scripting environment— which is part of all modern browsers—to read existing code parts, notably after they were randomized. Once the code has been read (e.g., using a memory disclosure vulnerability), an attacker can dynamically discover and chain gadgets for conventional code-reuse attacks. Mounting a successful JIT-ROP attack seemingly requires the ability to (i) read code fragments and identify suitable gadgets (otherwise the adversary would not know what to combine) and to (ii) execute them (so that the overall attack can be mounted). The recently proposed Execute-no-Read (XnR) schemes [2, 11, 12] consequently strive to eliminate JIT-ROP attacks by ensuring that executable code is non-readable, i.e., marking code sections as executable-only while explicitly removing the read privilege. Hence an adversary can no longer inspect the code after fine-grained code randomization techniques have been applied and should thus fail to identify suitable gadgets. As a more pointed statement: what cannot be read, cannot be leveraged. Our contributions: In this paper, we carefully revisit these seemingly inherent requirements for mounting a successful JIT-ROP attack. As our overall result, we show th...

Citation Context

...ly accepted that code sections must be read-only and executable while data sections must be nonexecutable to prevent attacks. Solutions like PaX [32] and DEP [5] prevent the execution of writable memory to prevent code injection attacks. If adversaries find a way to modify executable code, then they can attack the process by injecting and executing code of their choosing. PaX and DEP aim to partition the process into immutable and executable code sections and mutable but non-executable data sections to prevent such attacks. Researchers even argue that code sections should be execute-only [7], [15]. In addition, processes often include a variety of data that must be read-only. To enable the memory protection, the compiler toolchain produces the information necessary to inform the dynamic loader that certain program data should be restricted to read-only memory. Typically, an ELF file often includes a section for read-only data, namely .rodata. When the compiler detects constant variables in the program source, it adds those variables to the .rodata section of the generated object files. The linker then combines individual .rodata sections of the object files to form a single 3 .rodata s...

Citation Context

... However, preventing reading of code pages with execute-only memory is insufficient, because the adversary can disclose the code layout indirectly by reading code pointers on data pages. Crane et al. =-=[11]-=- presented Readactor, a security framework against all types of JIT-ROP attacks. Their solution allows for hiding code pointers and just-in-time compiled code from adversaries. However, very recently ...

Citation Context

... instruction fetches by the CPU. This avoids the small window of executable and readable pages. Nevertheless, HideM does not protect against code pointer leaks. The Readactor approach by Crane et al. =-=[14]-=- implements execute-only memory using the second level address translation feature in modern processors with support for hardware accelerated virtualization. Redactor introduces codepointer hiding, a ...

Citation Context

... However, preventing reading of code pages with execute-only memory is insufficient, because the adversary can disclose the code layout indirectly by reading code pointers on data pages. Crane et al. =-=[11]-=- presented Readactor, a security framework against all types of JIT-ROP attacks. Their solution allows for hiding code pointers and just-in-time compiled code from adversaries. However, very recently ...