PaX

Introduction

PaX: Twelve Years of Securing LinuxPaX Team

LATINOWARE 2012.10.10

PaX: Twelve Years of Securing LinuxFutureIntroduction

PaXFuture

About

LinuxI Kernel developed by a community of companies and volunteers
I Started in 1991 by Linus Torvalds
I The ’brain’ of the operating system (distributions, Android)
I Kernel vs. Userland

PaX: Twelve Years of Securing LinuxIntroduction

PaX

About

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)

PaX: Twelve Years of Securing LinuxFutureIntroduction

PaX

About

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

PaX: Twelve Years of Securing Linux

FutureIntroduction

PaXThe Problems

Software Development Lifecycle

I Idea/Design
I Development/Implementation
I Deployment/Configuration
I Operation/Maintenance

PaX: Twelve Years of Securing Linux

FuturePaX

Introduction

The Problems

Vulnerabilities
I Conceptual/Design mistakes
I e.g., lack of authentication or encryption
I Implementation mistakes
I Common Weakness Enumeration
I e.g., memory corruption bugs
I Deployment mistakes
I e.g., wrong file permissions
I Operation mistakes
I e.g., no monitoring/logging

PaX: Twelve Years of Securing Linux

FuturePaX

Introduction

FutureThe Problems

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)

PaX: Twelve Years of Securing LinuxPaXIntroduction

The Solutions

DesignI Prevent exploits from compromising userland applications
I non-executable memory pages
I runtime code generation control
I address space layout randomization (ASLR)
I control flow enforcement
I (limited) data flow protection
I Prevent exploits from compromising the kernel itself
I non-executable memory pages, etc

PaX: Twelve Years of Securing LinuxFuturePaX

Introduction

FutureThe Solutions

Implementation

I Static analysis (pay attention to clang/gcc/sparse warnings :)I Runtime checks
I userland/kernel separation
I memory object lifetime checking
I Fuzzing (e.g., trinity by Dave Jones)

PaX: Twelve Years of Securing LinuxPaXIntroduction

The Solutions

Deployment

I Mandatory Access Control (policies)
I Linux Security Modules (LSM)
I Apparmor, SELinux, Smack, Tomoyo, Yama, etc
I grsecurity, RSBAC, etc
I Logging, log analysis
I Incident management

PaX: Twelve Years of Securing Linux

FuturePaXIntroductionFuture

UserlandOverview

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)

PaX: Twelve Years of Securing LinuxPaXIntroduction

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)

PaX: Twelve Years of Securing LinuxPaXIntroduction

FutureUserland

ASLR

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)

PaX: Twelve Years of Securing LinuxIntroduction

PaXKernel 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 Instant free memory sanitization (SANITIZE)

PaX: Twelve Years of Securing LinuxFuture

PaX

Introduction

FutureKernel 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 mode

memory, vsyscall (amd64)
PaX: Twelve Years of Securing LinuxPaXIntroduction

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)

PaX: Twelve Years of Securing LinuxFuture

PaX

Introduction

FutureKernel 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)

PaX: Twelve Years of Securing LinuxPaX

Introduction

FutureKernel 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

PaX: Twelve Years of Securing LinuxIntroduction

PaXFuture

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

PaX: Twelve Years of Securing LinuxPaXIntroduction

Toolchain Support

Overview

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)

PaX: Twelve Years of Securing LinuxFutureIntroduction

PaXFuture

Toolchain Support

GCC plugins

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

PaX: Twelve Years of Securing LinuxPaXIntroduction

FutureToolchain 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

PaX: Twelve Years of Securing LinuxIntroduction

PaX

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

PaX: Twelve Years of Securing LinuxFuture

PaX

Introduction

Toolchain 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 pointersI 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

PaX: Twelve Years of Securing LinuxFuture

PaX

Introduction

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 Special cases: asm(), function return values, constants(intentional overflows), memory references, etc
I More in our blog
PaX: Twelve Years of Securing Linux

FutureIntroduction

PaX

UserlandOverview

I Control Flow Enforcement
I Size overflow detection & prevention

PaX: Twelve Years of Securing LinuxFuture

PaX

Introduction

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)

PaX: Twelve Years of Securing LinuxFuture

PaXIntroduction

FutureUserlandSize 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)

PaX: Twelve Years of Securing LinuxIntroduction

PaXKernel

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)

PaX: Twelve Years of Securing LinuxFuture

PaX

Introduction

FutureKernelLTO

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

PaX: Twelve Years of Securing LinuxIntroduction

PaXFutureKernel

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)

PaX: Twelve Years of Securing LinuxIntroduction

PaXKernelImproved 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)

PaX: Twelve Years of Securing Linux

FuturePaX

Introduction

FutureKernelImproved 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

PaX: Twelve Years of Securing LinuxPaX

Introduction

KernelImproved 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

PaX: Twelve Years of Securing LinuxFuture

PaX

Introduction

KernelControl 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

PaX: Twelve Years of Securing LinuxFuture

PaX

Introduction

FutureKernelKERNSEAL
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?)

PaX: Twelve Years of Securing LinuxPaX

Introduction

FutureKernelHYPEREXECI 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

PaX: Twelve Years of Securing Linuxhttp://pax.grsecurity.net
http://grsecurity.net
irc.oftc.net #pax #grsecurity