Too Subtle to Notice: Investigating Executable Stack Issues in Linux Systems

Code injection was a favored technique for attackers to exploit buffer overflow vulnerabilities decades ago.Subsequently, the widespread adoption of lightweight solutions like write-xor-execute (WX) effectively mitigated most of these attacks by disallowing writable-and-executable memory.However, we observe multiple concerning cases where software developers accidentally disabled WX and reintroduced executable stacks to popular applications.Although each violation has been properly fixed, a lingering question remains: what underlying factors contribute to these recurrent mistakes among developers, even in contemporary software development practices?In this paper, we conduct two investigations to gain a comprehensive understanding of the challenges associated with properly enforcing WX in Linux systems.First, we delve into program-hardening tools to assess whether experienced security developers consistently catch the necessary steps to avoid executable stacks.Second, we analyze the enforcement of WX on Linux by inspecting the source code of the compilation toolchain, the kernel, and the loader.Our investigation reveals that properly enforcing WX on Linux requires close collaboration among multiple components.These tools form a complex chain of trust and dependency to safeguard the program stack.However, developers, including security researchers, may overlook the subtle yet essential .note.GNU-stack section when writing assembly code for various purposes, and inadvertently introduce executable stacks.For example, 11 program-hardening tools implemented as inlined reference monitors (IRM) introduce executable stacks to all "hardened" applications.Based on these findings, we discuss potential exploitation scenarios by attackers and provide suggestions to mitigate this issue.