SafeInit: Comprehensive and Practical Mitigation of Uninitialized Read Vulnerabilities

Abstract

Usage of uninitialized values remains a common error in C/C++ code. This results not only in undefined and generally undesired behavior, but is also a cause of information disclosure and other security vulnerabilities. Existing solutions for mitigating such errors are not used in practice as they are either limited in scope (for example, only protecting the heap), or incur high runtime overhead. In this paper, we propose SafeInit, a practical protection system which hardens applications against such undefined behavior by guaranteeing initialization of all values on the heap and stack, every time they are allocated or come into scope. Doing so provides comprehensive protection against this class of vulnerabilities in generic programs, including both information disclosure and re-use/logic vulnerabilities. We show that, with carefully designed compiler optimizations, our implementation achieves sufficiently low overhead (<5% for typical server applications and SPEC CPU2006) to serve as a standard hardening protection in practical settings. Moreover, we show that we can effortlessly apply it to harden non-standard code, such as the Linux kernel, with low runtime overhead. Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author's employer if the paper was prepared within the scope of employment.

Untitled

“…However, in kernel exploitation, a local (unprivileged) adversary, armed with an arbitrary (kernel-level) memory disclosure vulnerability [84,99] has increased flexibility in mounting a JIT-ROP attack on a diversified kernel [64], as any user program may attack the OS. Therefore, kernel JIT-ROP attacks are not only easier to mount but are also facilitated by the abundance of memory disclosure vulnerabilities in kernel code [88,100,102,108].…”

“…However, in kernel exploitation, a local (unprivileged) adversary, armed with an arbitrary (kernel-level) memory disclosure vulnerability [84,99] has increased flexibility in mounting a JIT-ROP attack on a diversified kernel [64], as any user program may attack the OS. Therefore, kernel JIT-ROP attacks are not only easier to mount but are also facilitated by the abundance of memory disclosure vulnerabilities in kernel code [88,100,102,108].As a response to JIT-ROP attacks in user applications, execute-only memory prevents the (onthe-fly) discovery of gadgets by blocking read access to executable pages [27]. Nevertheless, given that widely used CPU architectures such as the x86 do not provide native support for enforcing execute-only permissions, such memory protection(s) can be achieved by relying on page table manipulation [9], TLB desynchronization [63], hardware virtualization [40,62], or techniques inspired by software-fault isolation (SFI) [86].…”

Type-After-Type

“…If the program erroneously references the original object, it executes a method controlled by the attacker. Likewise, common uninitialized read attacks exploit memory reuse to leak sensitive information, such as return addresses stored on the stack [27]. Temporal type safety prevents such attacks by preventing reuse of memory for different types.…”

“…More importantly, they protect only the heap, leaving the stack vulnerable. The reason is that the stack is notoriously performance-sensitive and extremely challenging to protect without incurring high overhead [27]. Unfortunately, stack-based temporal attacks are popular and, for instance, Microsoft reports that, over the last ten years, 52% of the uninitialized read vulnerabilities on its platform concerned the stack [28].…”

“…In contrast, Type-After-Type does not rely on complete call graph or points-to analysis, allowing support for complex, real-world applications. Finally, existing efficient stack protections provide comparable performance to Type-After-Type's on both stack and heap, but even on the stack alone they cannot address all the temporal vulnerabilities [22,25,27].…”