Transcript PaX (http://pageexec.virtualave.net)

Software Defense Mechanisms:
PaX and the future
past continuous
Who am I?

NOT Brad Spengler – I have decent ears

Tiago Assumpção <[email protected]>

NOT an academic

An undisciplined curious person with lots of energy
to be spent on whatever is valued by his self
Who am I? (cont.)

NOT a PaX developer… however…
Have had delightful discussions with PaX Team
about whatever blows your hair back
 Have been improving the project [2]
 Have been questioning the project [3]

In praise of hacking

“The speculations of Thales, Anaximander,
and Anaximenes are to be regarded as
scientific hypotheses (...) The questions they
asked were good questions, and their vigour
inspired subsequent investigators.”
RUSSELL, Bertrand; History of Western Philosophy - 1946. p. 37
What is PaX?


Quite simply: the greatest advance in
system security in over a decade that
you’ve never heard of
Less simply: It provides non-executable
memory pages and full address space
layout randomization (ASLR) for a wide
variety of architectures.
– Brad “grears” Spengler
What is PaX?

Linux kernel patch


Free-software & open-source is good for the
general researcher
Universal solutions: concepts easily extentend
to any modern platform
Why is PaX?

Given a vector:


Payload (code/data) injection
Context (memory/registers/etc.) manipulation

Intentional Control Flow modification
Outline

PaX




SEGMEXEC
PAGEEXEC
KERNEXEC
ASLR
RANDMMAP
 RANDKSTACK
 PIE


UDEREF
Outline (cont.)


PaX’ Facts
Past Continuous


Control Flow Verification
KERNSEAL
PaX - SEGMEXEC

SEGMEXEC is PaX’s implementation of perpage non-executable user pages using the
segmentation logic of IA-32 (Intel x86
architecture) and virtual memory area
mirroring (developed by PaX).
PaX – SEGMEXEC (cont.)

The segmentation logic is fairly straightforward:






Data Segment (DS)
Code Segment (CS)
There exist these two segments for user pages
as well as kernel pages.
PaX splits the address space down the middle:
the bottom half for data, the top for code.
Segmentation is a “window” into the address
space
No performance hit
PaX – SEGMEXEC (cont.)
Without SEGMEXEC
With SEGMEXEC
User
Code
Segment
User
Code & Data
Segments
1.5GB
3GB
User
Data
Segment
1.5GB
PaX – SEGMEXEC (cont.)


PaX’s VMA mirroring involves duplicating
every executable page in the lower half of
the address space into the upper half.
Instruction fetch attempts at addresses
located in the data segment that don’t
have any code located at its mirrored
address will cause a page fault. PaX
handles this page fault and kills the task.
PaX – SEGMEXEC (cont.)
08048000-0804c000
0804c000-0804d000
0804d000-08073000
40000000-40014000
40014000-40015000
40015000-40016000
4001e000-40145000
40145000-4014a000
4014a000-4014c000
4014c000-402d1000
bfffe000-c0000000
08048000-0804c000
0804c000-0804d000
0804d000-08079000
20000000-20014000
20014000-20015000
20015000-20016000
2001e000-20145000
20145000-2014a000
2014a000-2014c000
2014c000-202d1000
5ffff000-60000000
68048000-6804c000
80000000-80014000
8001e000-80145000
r-xp
rw-p
rw-p
r-xp
rw-p
rw-p
r-xp
rw-p
rw-p
r--p
rw-p
r-xp
rw-p
rw-p
r-xp
rw-p
rw-p
r-xp
rw-p
rw-p
r--p
rw-p
r-xp
r-xp
r-xp
/home/bradly/cat
/home/bradly/cat
/lib/ld-2.3.2.so
/lib/ld-2.3.2.so
Without SEGMEXEC
/lib/libc-2.3.2.so
/lib/libc-2.3.2.so
/usr/lib/locale/locale-archive
/home/bradly/cat
/home/bradly/cat
/lib/ld-2.3.2.so
/lib/ld-2.3.2.so
/lib/libc-2.3.2.so
/lib/libc-2.3.2.so
/usr/lib/locale/locale-archive
/home/bradly/cat
/lib/ld-2.3.2.so
/lib/libc-2.3.2.so
With SEGMEXEC
PaX – SEGMEXEC (cont.)
Instruction
fetch attempt at
0x08049000
Segmentation logic
translates
0x08049000 into
0x68049000
Success
Violation, process
is terminated
Does
0x68049000
belong to any
mapping?
YES
NO
PaX - PAGEEXEC



PAGEEXEC was PaX’s first implementation of
non-executable pages.
Because of SEGMEXEC, it’s not used anymore on
x86 (so I won’t discuss the implementation).
Platforms which support the executable bit in
hardware are implemented under PAGEEXEC
(currently alpha, ppc, parisc, sparc, sparc64,
amd64, and ia64)
PaX - KERNEXEC

KERNEXEC is PaX’s implementation of proper
page protection in the kernel







‘const’ finally means read only in the kernel
Read-only system call table
Read-only interrupt descriptor table (IDT)
Read-only global descriptor table (GDT)
Data is non-executable
Uses the same concept of segmentation as
SEGMEXEC
Cannot co-exist with module support (currently)
PaX - ASLR

Full ASLR randomizes the locations of the
following memory objects:






Executable image
Brk-managed heap
Library images
Mmap-managed heap
User space stack
Kernel space stack
PaX – ASLR (cont.)

Notes on amount of randomization:

The following values are for 32bit architectures. They
are larger on 64bit architectures, though not twice as
large (since they generally don’t use 64 bits for the
address space).




Stack – 24 bits (28 bits for argument/environment pages)
Mmap – 16 bits
Executable – 16 bits
Heap – 12 bits (or 24 bits if executable is randomized also)
PaX – ASLR (cont.)

The randomizations applied to each memory
region are independent of each other


Because PaX guarantees no arbitrary code execution,
exploits will most likely need to access different
memory regions.
So, if the exploit needs access to libraries and the
stack, the bits that must be guessed are the sum of
the two regions: 40 bits (or 44). The chance of such
an attack succeeding while depending on hard coded
addresses is effectively zero.
PaX – ASLR (cont.)
08048000-0804c000
0804c000-0804d000
0804d000-08078000
4edaa000-4edbe000
4edbe000-4edbf000
4edbf000-4edc0000
4edc8000-4eeef000
4eeef000-4eef4000
4eef4000-4eef6000
4eef6000-4f07b000
bf3dc000-bf3dd000
r-xp
rw-p
rw-p
r-xp
rw-p
rw-p
r-xp
rw-p
rw-p
r--p
rw-p
/home/bradly/cat
/home/bradly/cat
08048000-0804c000
0804c000-0804d000
0804d000-08070000
43d8c000-43da0000
43da0000-43da1000
43da1000-43da2000
43daa000-43ed1000
43ed1000-43ed6000
43ed6000-43ed8000
43ed8000-4405d000
archive
b54f9000-b54fa000
r-xp
rw-p
rw-p
r-xp
rw-p
rw-p
r-xp
rw-p
rw-p
r--p
/home/bradly/cat
/home/bradly/cat
rw-p
/lib/ld-2.3.2.so
/lib/ld-2.3.2.so
/lib/libc-2.3.2.so
/lib/libc-2.3.2.so
/usr/lib/locale/locale-archive
/lib/ld-2.3.2.so
/lib/ld-2.3.2.so
/lib/libc-2.3.2.so
/lib/libc-2.3.2.so
/usr/lib/locale/locale-
Two runs of a
binary with stack,
mmap, and heap
randomization
PaX – ASLR (cont.)

RANDKSTACK



Randomizes the kernel’s stack
Randomized on each system call, so infoleaking the randomization is useless
Randomizes 5 bits of the stack. Brute forcing
generally shouldn’t be possible, as each
attempt will most likely crash the kernel.
PaX – ASLR (cont.)

PIE





Special type of ELF binary (the same used for shared
libraries)
Position independent code (PIC)
Allows for relocation of the binary at a random
location
Needed to achieve Full ASLR
Requires a recompile and re-link of applications
PaX – Dangling Pointers

“Dangling pointers and wild pointers in
computer programming are pointers that
do not point to a valid object of the
appropriate type, or to a distinguished null
pointer value in languages which support
this”
Wikipedia
PaX – Dangling Pointers (cont.)

Most i386 OSs don't separate the
userland virtual address space from that
of the kernel.



Linux 2.6 has per-cpu GDTs; LDTs are
untouched
BSDs creates flat per-process LDTs
Windows creates flat per-process LDTs
PaX – Dangling Pointers (cont.)


Thence, whenever userland can make the
kernel (unexpectedly) dereference a
pointer within its range of control, it holds
ability to controlling the data (and,
possibly, code) flow of the kernel by virtue
of providing the attack elements in its own
address space.
Real-life [4]
PaX – UDEREF
Without UDEREF
With UDEREF
Kernel
Segments
1GB
Kernel & User
Segments
4GB
User
Segments
3GB
PaX – UDEREF (cont.)


Segment selectors are properly set
Few modifications are done regarding
user/kernel, kernel/kernel system calls
Facts

PaX



24/28 bit stack
randomization
16 bit mmap randomization
Completely implemented in
the kernel. Can be
implemented transparently
and retain binary
compatibility with all
distributions.
Facts (cont.)

PaX


Cuts usable address space
in half (though this can be
changed if it becomes a
problem)
Support for non-executable
and read-only kernel pages
on i386
Facts (cont.)

PaX




Per-system call kernel stack
randomization
Brk-managed heap
randomization
Ability to enable/disable all
features on a per binary
basis
Annihilates the possibility
of exploiting kernel
dereferencing pointer
vulnerabilities
Facts (cont.)

PaX


Supports the same user
space features on i386,
alpha, ppc, parisc, sparc,
sparc64, amd64, and ia64
Supports a per-page
implementation of nonexecutable pages on ppc
PaX – Past Continuous

Control Flow Verification

Basic blocks

A basic block is a sequence of statements that is
always entered at the beginning and exited at the
end, that is:



The first statement is a LABEL
The last statement is a JUMP or a CJUMP
There are no other LABELs, JUMPs, or JUMPs
APPEL, Andrew W.; Modern Compiler Implementation in ML- 2004. p. 180
PaX – Past Continuous

Control Flow Verification

Control Flow Graph (CFG)

“In computer science, a control flow graph (CFG)
is a representation, using graph notation, of all
paths that might be traversed through a program
during its execution. Each node in the graph
represents a basic block, (…)”
Wikipedia
PaX – Past Continuous

Control Flow Verification
PaX – Past Continuous

Control Flow Verification

Call graphs

“A call graph (also known as a call multigraph) is a
directed graph that represents calling relationship
among subroutines in a computer program”
Wikipedia
PaX – Past Continuous

Control Flow Verification
PaX – Past Continuous

Control Flow Verification

Static analysis
Build call graph for program P
 Build set S of callers
 Build set Q of callees
 Build set R of relationships between S and Q,
creating magic value for each

PaX – Past Continuous

Control Flow Verification

Code generation
Create proper prologues for every member of S
 Create proper epilogues for every member of Q


Magic Values

Hard to predict by exhaustive search values kept
within safe memory regions, they are verified in
run-time
PaX – Past Continuous

Control Flow Verification
callee
epilogue:
mov register,[esp]
cmp [register+1],MAGIC
jnz .1
retn
.1: jmp esp
caller:
call callee
test eax,MAGIC
PaX – Past Continuous

Control Flow Verification: Nondeterminism


Branch tables: run-time environment
OO virtual methods and function pointers
PaX – Past Continuous

Control Flow Verification

GOT entries


Made read-only by tweaking the static and the dynamic
linker
.ctors/.dtors

Made read-only by modifying the link-editor script
PaX – Past Continuous

Control Flow Verification

Are of a dynamic nature



atexit() handlers
malloc() callbacks
linuxthread callbacks (atfork() handlers)
PaX – Past Continuous (cont.)

Control Flow Verification: Results

Breaks my attack [3] – brief explanation? –
and anything that rely on the following
premisses
execute existing code out of original program
order
 execute existing code in original program order
with arbitrary data

PaX – Past Continuous (cont.)

Control Flow Verification: Results

Opens a wide range of possibilities for
improving systemic security
Call graph trust relationship ensures that (in most
cases) all control flow (including intra-procedural)
can’t be broken with a very low performance
impact
 Call graph trust relationship allows data integrity
verification (KERNSEAL)

PaX – Past Continuous

KERNSEAL

Liveness Analysis

“We say a variable is live if it holds a value that
may be needed in the future, so this analysis is
called liveness analysis”
APPEL, Andrew W.; Modern Compiler Implementation in ML- 2004. p. 211
PaX – Past Continuous

KERNSEAL

The set of live variables at line L2 is {b, c},
but the set of live variables at line L1 is only
{b} since variable c is updated in line 2. The
value of variable a is never used, so the
variable is never live.
L1: b := 3;
L2: c := 5;
L3: a := b + c;
goto L1;
PaX – Past Continuous

KERNSEAL

Liveness Analysis: Dataflow equations

“Liveness of variables ‘flows’ around the edges of
the control-flow graph; determining the live range
of each variable is na example of a dataflow
problem”
APPEL, Andrew W.; Modern Compiler Implementation in ML- 2004. p. 213
PaX – Past Continuous

KERNSEAL

Liveness Analysis: Terminology
Out-edges: nodes leading to successor nodes
 In-edges: nodes coming from predecesor nodes

pred[n], holding the set of predecessors of node n
 succ[n], holding the set of successors of node n

PaX – Past Continuous

KERNSEAL

Liveness Analysis: Terminology
Uses: the set of variables in use at a given node
 Defs: the set of variables assigned at a given

node
PaX – Past Continuous

KERNSEAL

Liveness Analysis: Terminology

Liveness: “A variable is live on an edge if there is a
directed path from tha edge to a use of the
variable that does not go through any def. A
variable is live-in at a node if it is live on any of the
in-edges of that node; it is live-out at a node if it is
live on any of the out-edges of the node.”
APPEL, Andrew W.; Modern Compiler Implementation in ML- 2004. p. 213
PaX – Past Continuous

KERNSEAL

Liveness Analysis:

The dataflow equations used for a given basic
block s and exiting block f in live variable analysis
Wikipedia
PaX – Past Continuous

KERNSEAL

Liveness Analysis

Allows access control of specific code procedures –
known a priori – towards sensitive data (kernel
data)
Process structures
 Object Credentials
 Kernel Function Pointers


And others
PaX – Past Continuous

KERNSEAL

Design
Unreadable
memory pages
Read-only
memory pages
Read-write
memory pages
PaX – Past Continuous

KERNSEAL

Example: protect user credentials info
Perform liveness analysis for deriving specific code
blocks that may have legit read/write access to it
 Set memory properties holding the data structures
to read-only
 Embed (through instrumentation) write-key
procedure to allowing legit code to access the
structure

PaX – Past Continuous

KERNSEAL

Results
Strengthen of Trusted Computing Base (TCB)
 Defense in Depth: even if compromised, kernel
operations towards sensitive memory areas are
restricted by nature
 Provides strong trust-relationship infrastructure to
creating several other protection mechanisms in
different layers of the kernel as well as of the user
space

Questions?
Thanks!!!
contact me at [email protected]
References




[1] http://pax.grsecurity.net
[2] http://www.phrack.org/issues.html?issue=63&id=4
[3] http://assumpcao.org/content/publications/Breaking_PaX_ASLR.ppt
[4] http://lists.immunitysec.com/pipermail/dailydave/2007March/004133.html