Retrofitting XoM for Stripped Binaries without Embedded Data Relocation

💡 Research Summary

The paper addresses the growing threat of just‑in‑time return‑oriented programming (JIT‑ROP), a sophisticated code‑reuse attack that exploits memory‑disclosure vulnerabilities to harvest gadgets from a running program and assemble a malicious payload on the fly. Traditional defenses such as W⊕X (write‑xor‑execute) prevent writable‑executable pages but still allow arbitrary reads of code, which JIT‑ROP leverages to bypass fine‑grained code randomization. Execute‑only memory (XoM) has been proposed as a countermeasure because it revokes read permission from executable pages, thereby blocking gadget discovery.

Existing XoM implementations suffer from two major drawbacks. First, they either rely on software emulation or on hardware features (e.g., extended page tables) that impose significant performance penalties or require virtualization. Second, they assume a strict separation between code and data within a page. In practice, modern compilers, inline assembly, jump tables, and static read‑only data frequently embed data bytes inside code sections. When XoM is applied at page granularity, legitimate data‑in‑code reads trigger false positives, causing program crashes or severe compatibility issues. Prior work therefore either requires recompilation with custom toolchains, binary patching with debug symbols, or architectural modifications—none of which are feasible for legacy or commercial‑off‑the‑shelf (COTS) binaries.

PXoM (Practical XoM) introduces a hardware‑assisted, fine‑grained protection scheme that works on stripped x86‑64 binaries without any embedded‑data relocation. The core idea is to exploit Intel Memory Protection Keys (MPK), a feature that assigns a 4‑bit key to each page and allows per‑thread permission changes via a fast register write. PXoM extends this concept by subdividing a page into smaller blocks (e.g., 64‑byte granules) and assigning distinct MPK keys to “code‑only” blocks and “data‑allowed” blocks. This enables the kernel to enforce read‑only (execute‑only) permissions on genuine code while still permitting legitimate reads of embedded data.

To identify which bytes belong to code and which to data, the authors devise a Unidirectional Disassembly algorithm. Starting from known entry points, the algorithm walks forward, decoding instructions until it encounters an undecodable byte or a control‑flow break; the subsequent region is then classified as data. By proceeding in a single direction, the method avoids the ambiguities that plague bidirectional or global disassembly tools, achieving high precision even without debug symbols.

Implementation details: a modified Linux ELF loader parses the binary, creates MPK‑protected mappings, and tags each block with the appropriate key. At runtime, a kernel‑level monitor intercepts every read request to executable pages. If the address falls within a code‑only block, the read is denied; if it falls within a data‑allowed block, the request proceeds. To reduce the cost of frequent key switches, PXoM adds a lightweight cache‑like optimization that keeps the most‑accessed data‑blocks’ keys active for the current thread.

Security evaluation shows that after PXoM protection, the number of discoverable gadgets drops dramatically, leaving insufficient variety to construct a functional JIT‑ROP chain. Performance evaluation spans microbenchmarks (lmbench), macrobenchmarks (SPEC CPU2006/2017), and real‑world workloads (three web servers and four database systems). Across all tests, PXoM incurs an average runtime overhead of only 0.22 %–0.82 %, with negligible memory overhead.

The paper’s contributions are threefold: (1) a novel hardware‑assisted fine‑grained permission model using MPK, (2) a reliable, symbol‑free method for separating code and embedded data, eliminating the need for error‑prone data relocation, and (3) an end‑to‑end, kernel‑integrated XoM solution that works on unmodified, stripped binaries. The authors release the source code and datasets on Zenodo, facilitating reproducibility and future research. In summary, PXoM demonstrates that practical, low‑overhead XoM protection for legacy binaries is achievable, substantially raising the bar against memory‑disclosure‑based JIT‑ROP attacks.