About

Present

Past

20 Years of PaX
PaX Team

SSTIC 2012.06.06

20 Years of PaX

FutureAboutPast

About
Introduction
Design Concepts
PastUserland
Present
Kernel Self-Protection
Toolchain Support
FutureUserlandKernel

20 Years of PaX

PresentFutureAbout

Past

Present

Introduction

What is PaX?
I Host Intrusion Prevention System (HIPS)I Focus: exploits for memory corruption bugs
I Bugs vs. exploits vs. exploit techniques
I Threat model: arbitrary read/write access to memory
I Local/remote and userland/kernel
I Linux 2.2.x-2.4.x-2.6.x-3.x (2000-2012)
I Developed by the PaX Team :)I grsecurity by Brad Spengler (spender)

20 Years of PaX

FutureAbout

Past

Present

Introduction

PaX Features

I Runtime code generation control (non-executable pages)
I Address Space Layout Randomization (ASLR)I Kernel self-protection
I Various infrastructure changes for supporting all the above

20 Years of PaX

FutureAbout

Past

Present

Design Concepts

Vulnerability Roadmap
Where Things Can Go Wrong

I Idea/Design
I Education, talent, modeling, art vs. science
I Development
I Deployment/Configuration/Operation/Maintenance
I Procedures (manuals, standards, etc)
I Logging/monitoring/analysis

20 Years of PaX

FutureAbout

Past

Present

Design Concepts

How to Improve: Development

I Education
I Tools/Toolchain (analysis, runtime checks)
I Testing/Exploiting (fuzzing)
I Exploit-resistant runtime environment (PaX :)I Instead of finding the exploitable bugs, make themnon-exploitable

20 Years of PaX

FutureAbout

Past

PresentFuture

Design Concepts

Exploit Techniques

I Focus: exploits against memory corruption bugs
I Execute injected code (shellcode)
I Execute existing code out-of-(intended)-order (return-to-libc,ROP/JOP)I Execute existing code in-(intended)-order (data-only attacks)

20 Years of PaX

AboutPast

About
Introduction
Design Concepts
Past
UserlandPresent
Kernel Self-Protection
Toolchain Support
FutureUserlandKernel

20 Years of PaX

PresentFutureAbout

Past

Present

FutureUserlandOverview

I Non-executable page support on i386

(PAGEEXEC/SEGMEXEC)I Runtime code generation control (MPROTECT)I Address Space Layout Randomization (ASLR, RANDEXEC)
I Compatibility (per-binary feature control, text relocations,trampoline emulation)

20 Years of PaX

About

Past

Present

FutureUserland

PAGEEXEC/SEGMEXEC/MPROTECTI PAGEEXEC: paging based simulation of non-executable pages

on i386 (in 2000, pre-NX days)
I SEGMEXEC: segmentation based simulation ofnon-executable pages on i386 (in 2002)
I MPROTECT: runtime code generation control (in 2000)
I NX-bit is in wide use nowadays (BSDs, iOS, Linux,Windows/DEP, etc)

20 Years of PaX

About

Past

PresentFuture

UserlandASLR

I Introduced in July 2001 as a stopgap measure (not how itturned out :)I Idea: artificially inflated entropy in memory addresses (bothcode and data)
I Reduced exploit reliability
I In wide use nowadays (BSDs, iOS, Linux, Windows, etc)

20 Years of PaX

AboutPast

AboutIntroduction
Design Concepts
PastUserland
PresentKernel Self-Protection
Toolchain Support
FutureUserlandKernel

20 Years of PaX

PresentFutureAbout

Past

Present

Kernel Self-Protection

Overview

I Non-executable kernel pages (KERNEXEC)
I Read-only kernel data (KERNEXEC, CONSTIFY)
I Userland/kernel address space separation (UDEREF)
I Restricted userland-kernel copying (USERCOPY)
I Userland/kernel copying race reduction
I Instant free memory sanitization (SANITIZE)

20 Years of PaX

FutureAboutPast

PresentFuture

Kernel Self-Protection

KERNEXECI Non-executable pages for the kernel’s address space
I Executable userland pages must not be executable from kernelmode
I i386: code segment excludes the entire userland address space
I amd64: compiler plugin or UDEREF
I Supervisory Mode Execution Protection (CR4.SMEP) since Ivy

Bridge (in mainline linux already)
I Page table cleanup: read-write vs. read-execute regions(kmaps)
I Special cases: boot/BIOS, ACPI, EFI, PNP, v8086 modememory, vsyscall (amd64)
20 Years of PaX

About

Past

Present

Kernel Self-Protection

Constification

I Creates read-only data mappings
I Moves data into read-only mappings (.rodata,.data..read_only)
I Patches (descriptor tables, top level page tables, etc)
I Compiler plugin (ops structures)

20 Years of PaX

FutureAbout

Past

PresentFuture

Kernel Self-Protection

UDEREFI Prevents unintended userland access by kernel code
I Disadvantage of the shared user/kernel address space
I i386: based on segmentation
I data segment excludes the entire userland address space
I amd64: based on paging
I remaps userland page tables as non-executable while in kernelmode
I needs per-cpu page global directory (PGD)

20 Years of PaX

AboutPast

PresentFutureKernel Self-Protection

USERCOPY

I Bounds checking for copying from kernel memory to userland(info leak) or vice versa (buffer overflow)
I spender’s idea: ksize can determine the object’s size fromthe object’s address
I Originally heap (slab) buffers only
I Limited stack buffer support (see Future section)
I Disables SLUB merging

20 Years of PaX

AboutPastPresentFuture

Kernel Self-Protection

Userland/Kernel Copying Races
I Userland/kernel copying can (be made to) sleep
I During that sleep userland memory can change
I Time-Of-Check-To-Time-Of-Use race (TOCTTOU)
I Unbounded userland/kernel copying based exploits become

controllable
I Basically prefaults the userland range
I Reduces but does not eliminate race window
I Detects controlled unbounded copies before the actual copy

20 Years of PaX

About

Past

PresentFuture

Kernel Self-Protection

SANITIZEI Reduces potential info leaks from kernel memory to userland
I Freed memory is cleared immediately
I Low-level page allocator, not slab layer
I Works on whole pages, not individual heap objects
I Kernel stacks on task death
I Anonymous userland mappings on munmap
I Anti-forensics vs. privacy

20 Years of PaX

About

Past

PresentToolchain SupportOverview

I gcc plugins (gcc 4.5-4.7)
I Kernel stack leak reduction (STACKLEAK)
I Function pointer structure constification (CONSTIFY)
I User/kernel address space separation for code only

(KERNEXEC)I Size parameter overflow detection&prevention(SIZE_OVERFLOW)

20 Years of PaX

FutureAbout

Past

PresentFuture

Toolchain Support

GCC plugins

I Loadable module system introduced in gcc 4.5
I Loaded early right after command line parsing
I No well defined API, all public symbols available for plugin use
I Typical (intended :) use: new IPA/GIMPLE/RTL passes

20 Years of PaX

About

Past

PresentFuture

Toolchain Support

STACKLEAK plugin
I First plugin :)I Reduces kernel stack information leaks
I Before a kernel/userland transition the used kernel stack partis cleared
I Stack depth is recorded in functions having a big enoughstack frame
I Sideeffect: finds all (potentially exploitable :) alloca calls
I Special paths for ptrace/auditing
I Problems: considerable overhead, races, leaks from a single

syscall still possible

20 Years of PaX

About

Past

Present

Toolchain Support

CONSTIFY plugin

I Automatic constification of ops structures (200+ in linux)
I Structures with function pointer members only
I Structures explicitly marked with a do_const attribute
I no_const attribute for special cases
I Local variables not allowed

20 Years of PaX

FutureAbout

Past

PresentToolchain Support

KERNEXEC plugin
I Prevents executing userland code on amd64
I i386 achieves this already via segmentation
I Sets most significant bit in all function pointers
I Userland addresses become non-canonical ones
I GIMPLE pass: C function pointers
I RTL pass: return values
I Special cases: assembly source, asm()
I Two methods: bts vs. or (reserves %r10 for bitmask)
I Compatibility vs. performance

20 Years of PaX

FutureAbout

Past

Present

Toolchain Support

SIZE_OVERFLOW plugin
I Detects integer overflows in expressions used as a size

parameter: kmalloc(count * sizeof...)
I Written by Emese Révfy
I Proper implementation of spender’s old idea
I Initial set of functions/parameters marked by thesize_overflow function attribute
I Walks use-def chains and duplicates statements using adouble-wide integer type
I SImode/DImode vs. DImode/TImodeI Special cases: asm(), function return values, constants(intentional overflows), etc
I More in the blog Real Soon Now:
http://forums.grsecurity.net/viewforum.php?f=7
20 Years of PaX

FutureAboutPast

About
Introduction
Design Concepts
PastUserland
PresentKernel Self-Protection
Toolchain SupportFuture
UserlandKernel

20 Years of PaX

PresentFutureAbout

Past

PresentUserland

Overview

I Control Flow Enforcement
I Size overflow detection & prevention
I Kernel-assisted use-after-free detection

20 Years of PaX

FutureAbout

Past

Present

UserlandControl Flow Enforcement

I Compiler plugin
I (No) binary-only code support
I Assembly source instrumentation
I Runtime code generation support (Just-In-Time compilerengines)

20 Years of PaX

FutureAbout

Past

PresentFuture

UserlandSize Overflow Detection & Prevention
I Same plugin as used for the kernel
I Unique problems (build system integration, namespacecollisions, etc)
I Already in progress (apache, glib, glibc, openssl, php, samba,

syslog-ng, etc)
I Would have caught CVE-2012-2110 (ASN1 BIO vulnerability)
I Would have caught CVE-2012-2131 (the incorrect fix to0.9.8v) too
I Needs support for c++ (chromium, firefox, etc)

20 Years of PaX

AboutPast

PresentUserland

Kernel-Assisted Use-After-Free Detection

I Idea: 64-bit address spaces are large enough to prevent

address reuse
I Kernel modification to mmap
I Cost: kernel data structures (page tables, vma)
I Userland memory allocator cooperation

20 Years of PaX

FutureAbout

Past

PresentKernel

Overview
I Link Time Optimization (LTO)I LLVM/clang support
I Improved USERCOPY
I Improved REFCOUNTI Improved STACKLEAKI Control Flow Enforcement
I Limited data flow enforcement (KERNSEAL)I PaX for hypervisors (HYPEREXEC)

20 Years of PaX

FutureAbout

Past

PresentFuture

KernelLTO

I Mostly works with gcc 4.7
I Takes 5 minutes and 4GB RAM on a quad-core Sandy Bridge
I Problems: KALLSYMS, tracing, initcalls, section attributes
I Better support for other plugins (CONSTIFY, REFCOUNT,SIZE_OVERFLOW, STACKLEAK, USERCOPY)I New plugins: static stack overflow checking, sparse attributes,etc

20 Years of PaX

About

Past

PresentFutureKernel

LLVM/clang

I http://llvm.org and http://clang.llvm.org
I Mostly works with linux-side patches only
I clang 3.1 and -integrated-as, .code16gcc/.code16
I -fcatch-undefined-behavior (ext4 triggers it on mount)
I LTO
I Port the gcc plugins to llvm
I New plugins for clang (not really feasible with gcc)

20 Years of PaXAbout

Past

Present

KernelImproved USERCOPY

I Problem: kmalloc-* slabs
I Separate them into kmalloc-user-* and kmalloc-*
I Mark only kmalloc-user-* with SLAB_USERCOPY
I kmalloc_user vs. kmalloc
I Problem: find affected kmalloc calls
I Needs whole-tree static analysis (LTO plugin)

20 Years of PaX

FutureAbout

Past

PresentFuture

KernelImproved REFCOUNTI Problem: false positives (not every atomic_t variable is areference counter)
I Statistical counters and unique identifiers (only increments),bitflags (directly set only)
I Needs whole-tree static analysis (LTO plugin) to find theabove kind of variables

20 Years of PaX

About

Past

PresentKernel

Improved STACKLEAK

I Problem: performance impact, races
I New per-task kernel stack used for USERCOPY
I Problem: find affected local variables
I Needs whole-tree static analysis (LTO plugin) to find theabove kind of variables

20 Years of PaX

FutureAbout

Past

PresentKernel

Control Flow Enforcement

I Compiler plugin
I (No) support for binary-only modules
I Assembly source instrumentation
I Runtime code generation support?
I Performance impact is critical (<5% desired), very hard

problem

20 Years of PaX

FutureAbout

Past

PresentFuture

KernelKERNSEAL
I Ensures that certain kernel data cannot be modified

unintentionally (arbitrary write bug)
I Credential structures, memory management data, filesystem

metadata/data (page cache), etc
I Read-only slab
I Read-only kernel stacks (except for the current one :)I Trusted pointer chains, trusted root pointers (current stack,per-cpu data?)

20 Years of PaX

About

Past

PresentFuture

KernelHYPEREXECI Virtualization does not increase security (despite marketing :)I It introduces a new privilege level in the software stack(hypervisors)
I Hypervisors represent additional complexity and bugs
I Apply the kernel-self protection features to the hypervisor(Xen, KVM)
I Enforce (guest) kernel self-protection from a higher privilege

level

20 Years of PaXhttp://pax.grsecurity.net
http://grsecurity.net
irc.oftc.net #pax #grsecurity