We have noticed multiple alarming cases where software developers accidentally disabled the W⊕X protection in their programs including popular applications such as Electron, VSCode, and CockroachDB. These cases are unexpected since W⊕X is a mature technique and should have been enabled automatically by default.
Our investigation revealed that W⊕X was disabled due to the inclusion of hand-written assembly files that missed a section directive: .section .note.GNU-stack,"",@progbits. This directive declares a .note.GNU-stack section to indicate the stack should not be executable. Developers usually missed this directive and inadvertently made the application stack executable when manually writing assembly code for various purposes. We term this problem BADASS.
Even experienced security researchers and recognized developers may miss this directive when developing security-hardening tools (e.g., inlined reference monitors). We conduct an investigation on the presence of BADASS issue in inlined reference monitors (IRM). 11 out of 21 investigated IRMs have the BADASS issue and introduce executable stacks to hardened applications.
The following table lists all 21 investigated IRMs. We create a separate page for every IRM that suffers from BADASS issue. The page includes instructions on how to reproduce this issue, a link to a virtual machine image for quick reproduction, the root cause analysis, and the timeline of the issue report and fix.
| Category | IRM | Conference | Assembly | BADASS | Status |
|---|---|---|---|---|---|
| CFI | binCFI | USENIX SEC'13 | yes | no | - |
| MCFI | PLDI'14 | yes | yes | fixed | |
| LLVM CFI | USENIX SEC'14 | no | no | - | |
| RockJIT | CCS'14 | yes | yes | fixed | |
| πCFI | CCS'15 | yes | yes | fixed | |
| PathArmor | CCS'15 | yes | yes | won't fix | |
| μCFI | CCS'18 | yes | no | - | |
| Android kCFI | - | no | no | - | |
| SFI | Wasmtime | - | no | no | - |
| Debloating | Razor | USENIX SEC'19 | yes | no | - |
| Isolation | ERIM | USENIX SEC'19 | yes | yes | fixed |
| Donky | USENIX SEC'20 | yes | yes | no risk | |
| Binary Rewriting | Uroboros | USENIX SEC'15 | yes | yes | checking |
| Ramblr | NDSS'17 | yes | yes | will fix | |
| Multiverse | NDSS'18 | no | no | - | |
| Egalito | ASPLOS'20 | no | no | - | |
| RetroWrite | S&P'20 | yes | yes | fixed | |
| E9Patch | PLDI'20 | no | no | - | |
| Ddisasm <= 1.5.4 | USENIX SEC'20 | yes | yes | fixed | |
| ARMore | USENIX SEC'23 | yes | yes | fixed | |
| SAFER | USENIX SEC'23 | yes | no | - |
We also conduct a systematic W⊕X enforcement analysis by inspecting the source code of the compilation chain, the kernel, and the loader. Based on the analysis, we summarize the complicated logic related to stack executable permission in the following figure. The first row shows the normal compilation workflow where no BADASS exists. Red lines demonstrate the potential locations where developers may miss necessary attributes and introduce executable stacks.
We summarize some error-prone scenarios that may disable W⊕X inadvertently.
- Missing .section .note.GNU-stack,"",@progbits in hand-written assembly code
- Define nested functions in source code.
- Link an object with SEC_CODE set in .note.GNU-stack.
- Load a shared library with PF_X set in PT_GNU_STACK.
- Include object without .note.GNU-stack or binary without PT_GNU_STACK on 32-bit architecture.
Please check our paper published on NDSS 2025 for more details.
Too Subtle to Notice: Investigating Executable Stack Issues in Linux Systems
@inproceedings{ye:badass,
title = {{Too Subtle to Notice: Investigating Executable Stack Issues in Linux Systems}},
author = {Hengkai Ye and Hong Hu},
booktitle = {Proceedings of the 32nd Network and Distributed System Security Symposium (NDSS 2025)},
month = {feb},
year = {2025},
address = {San Diego, CA},
}We appreciate the assistance of the IRM developers for their detailed discussions and prompt resolution of reported issues. This research was supported by National Science Foundation (NSF) under grants CNS-2247652 and CNS-2339848.