PaX basic
Posted on November 1, 2024 • 4 minutes • 759 words
I’m tired of chasing individual CVEs. What if we could eliminate that entire class of vulnerabilities altogether?🤔
This is the first post of this series where I look into solution to solve the above problem.
PaX is one of the attempt to do so. If it’s so good, why hasn’t it make it into kernel mainline? etc…
PaX Overview
PaX is a security patchset developed by gcsecurity that focuses on memory corruption protection. It implements various features designed to defend against code injection and execution attacks, such as buffer overflows and ROP (Return-Oriented Programming) exploits. Below are the key features of PaX.
Key Features of PaX
1. PAGEEXEC (Paging-based Non-Executable Pages)
PAGEEXEC is a sophisticated mechanism that implements non-executable memory protection to enhance security.
In Unix-like operating systems, memory pages can be set to read, write, or execute. If a page is both writable and executable, attackers can potentially inject malicious code into it and execute it—this is a common exploitation tactic.
How PAGEEXEC Works:
- NX Bit Enforcement: PAGEEXEC uses the NX (non-executable) bit in modern processors to prevent code execution in memory pages marked as data-only. If code is executed in these areas, PAGEEXEC triggers an exception, blocking the exploit.
- Software Simulation on Older CPUs: On CPUs that don’t support the NX bit, PAGEEXEC emulates this protection using software-based techniques (e.g., segment-based permissions on x86 architectures).
Targeted Attacks:
- PAGEEXEC helps defend against attacks like buffer overflows, stack overflows, and certain types of ROP attacks by ensuring writable pages cannot be executed.
Compatibility Considerations:
- Programs like Google Chrome NaCl Helper (which uses dynamic code generation via JIT compilers) may require disabling PAGEEXEC for compatibility.
Most of the computers sold in the last 20 years already has NX supported.
2. SEGMEXEC (Segmentation-based Non-Executable Pages)
A feature that prevents executing code in the data segment using segmentation on x86_32.
SEGMEXEC is implemented through the segmentation feature of x86_32 architecture, making it applicable only to x86_32 systems. It functions similarly to PAGEEXEC but is specific to the segmentation method used in this architecture.
3. MPROTECT (W^X Writable-Xor-Executable Memory Pages)
MPROTECT restricts memory pages from being both writable and executable, which is a common protection mechanism against buffer overflow and code injection attacks.
How MPROTECT Works:
- PAGEEXEC prevents code execution in data regions, while MPROTECT ensures that applications cannot make memory pages both writable and executable.
- MPROTECT works in conjunction with PAGEEXEC to enforce stricter memory protection, especially for attacks that attempt to modify memory permissions during runtime, such as JIT compilation.
Targeted Attacks:
- Code injection
- JIT attacks
- Certain ROP exploits
Examples of Affected Programs:
- QEMU
- Chromium
- Python interpreter
- Java VM
| Feature | PAGEEXEC | MPROTECT |
|---|---|---|
| Focus | Enforces non-executable memory for non-code pages | Restricts making pages both writable and executable |
| Protection Mechanism | Uses NX bit or segmentation tricks | Blocks runtime memory permission changes by applications |
| Targeted Attacks | Buffer overflows, code injection | Code injection, JIT attacks, certain ROP exploits |
| Behavior | Automatic enforcement of non-executable memory | Requires explicit permission for writable-executable memory |
4. EMUTRAMP (Emulated Trampolines)
Emulated trampolines are short pieces of executable code that redirect execution flow, often used in JIT compilation or during ROP chain exploits. These trampolines allow attackers to jump between different code sections, enabling payload execution or control flow redirection.
How EMUTRAMP Works:
- EMUTRAMP blocks exploits that attempt to hijack execution through trampolines, ensuring that they cannot be created, modified, or executed in ways that compromise system integrity.
5. ASLR (Address Space Layout Randomization)
ASLR is a security technique that randomizes memory addresses used by system components, such as the stack, heap, libraries, and memory mappings. This makes it more difficult for attackers to predict memory locations and successfully exploit vulnerabilities.
PaX vs. Linux Kernel ASLR:
| Feature | PaX ASLR | Linux Kernel ASLR |
|---|---|---|
| Randomization Range | Larger, more aggressive randomization of memory | Limited randomization, smaller range than PaX |
| Randomization Granularity | More fine-grained randomization (stack, heap, libraries, etc.) | Randomizes stack, heap, and shared libraries |
| Security Level | Stronger protection against advanced attacks like ROP | Basic protection against simple buffer overflows |
| Flexibility | Less flexible, requires PaX patches for the kernel | Configurable via sysctl parameters |
| Performance Impact | May have a higher performance overhead due to aggressive randomization | Generally lower overhead in comparison |
PaX Flags
This is the list of PaX flags you can mask binaries with.
-p|P PAGEEXEC: use NX-bit to mark unexecutable pages
-e|E EMUTRAMP: emulate stack trampolines
-m|M MPROTECT: write-xor-execute in mmap/mprotect(2) syscalls
-r|R RANDMMAP: address space layout randomization (ASLR)
-s|S SEGMEXEC: segmentation-based NX-bit emulation
In the second post of this series, I will focus more on why this hasn’t made it into kernel mainline yet.