SLIDE 1
C/C++ programs are vulnerable
- Lots of exis5ng code in C and C++
- More being wriEen every day
- C/C++ programs are prone to bounds errors
- Bounds errors can be exploited by aEackers
2
Baggyboundschecking PeriklisAkri5dis,ManuelCosta, - - PowerPoint PPT Presentation
Baggyboundschecking PeriklisAkri5dis,ManuelCosta, - - PowerPoint PPT Presentation
Baggyboundschecking PeriklisAkri5dis,ManuelCosta, MiguelCastro,StevenHand C/C++programsarevulnerable Lotsofexis5ngcodeinCandC++ MorebeingwriEeneveryday
SLIDE 2
SLIDE 3
Previous solu5ons are not enough
- Finding all bugs is unfeasible
- Using safe languages requires por5ng
- Exis5ng solu5ons using fat pointers (Ccured,
Cyclone) break binary compa5bility
- Backwards compa5ble solu5ons are slow
- And performance is cri5cal for adop5on
3
SLIDE 4
Baggy bounds checking (BBC)
- Enforce alloca5on instead of object bounds
- Constrain alloca5on sizes and alignment to
powers of two
- Fit size in one byte
- No need to store base address
- Fast lookup using linear table
4
SLIDE 5
BBC Benefits
- Works on unmodified source code
- Broad coverage of aEacks
- Interoperability with uninstrumented binaries
- Good performance
– 30% average CPU overhead
- 6‐fold improvement over previous approaches on SPEC
– 7.5% average memory overhead – 8% throughput degrada5on for Apache
5
SLIDE 6
System overview
6
SLIDE 7
AEack Example
- Pointers start off valid
p = malloc(200);
- May become invalid
q = p + 300;
- And then can be used to hijack the program
*q = 0x00000BAD
7
SLIDE 8
Tradi5onal Bounds Checking [Jones and Kelly]
- Use table to map allocated range to bounds
p = malloc(200);
- Lookup bounds using source p
q = p + 300;
- Check result q using bounds
- Note that source pointer p assumed valid
– points to alloca5on or result of checked arithme5c – maintain this invariant throughout execu5on
- But keeping bounds informa5on is expensive…
8
SLIDE 9
Baggy Bounds
- Pad alloca5ons to power of 2
– malloc(200) ‐> malloc(256)
- Align to alloca5on size
– Upper bound: FF – Lower bound: 00
- Can recover bounds using
– The valid source pointer – The binary logarithm of the alloca5on size
9
SLIDE 10
Bound table implementa5on
- Previous solu5ons need e.g. splay tree to
lookup bounds for a given source pointer
- If force alloca5ons to be a mul5ple of 16 byte
slots, can use an array with 1 byte per slot
10
SLIDE 11
Efficient table lookup
11
mov eax, p ; Copy pointer shr eax, 4 ; Right‐shio by 4 mov al, [TABLE+eax] ; One memory read
- Loads alloca5on size logarithm in register %al
- However:
- No need to recover explicit bounds
- Use valid pointer and alloca5on size directly
SLIDE 12
Efficient Checks
q = p + 300; mov ebx, p ; copy source 0x88888800 xor ebx, q ; xor with result 0x8888892C 0x0000012C shr ebx, al ; right shio >> 8 ; by table entry 0x00000001 jnz error ; check for zero !!!
12
SLIDE 13
(Legal) Out‐of‐bounds pointers
- C programs can use out‐of‐bounds pointers
- Cannot dereference
- Can use in pointer arithme5c
- C standard allows only one byte beyond object
– Some programs go beyond, or below object e.g. char *array = malloc(100) – 1; // now can use array[1..100]
13
SLIDE 14
Dealing with OOB pointers
- 1. Mark to avoid dereference
– Set pointer top bit [Dhurja5 et al.] – Protect top half of address space
- 2. Recover valid pointer if marked
– Can use extra data structure [Ruwase and Lam] – BBC: support most cases without a data structure – (can support more in 64‐bit mode – see later)
14
SLIDE 15
Common out‐of‐bounds pointers
15
SLIDE 16
Extra check in fast path
16
SLIDE 17
Op5mized fast path
17
SLIDE 18
Memory Alloca5ons
- Heap using binary buddy system
– Perfect fit for baggy bounds
- Align stack frames at run5me
– Only if contains array or address taken variable
- Pad and align globals at compile 5me
- Memory allocated by uninstrumented code
has default table entry
– Default value 31: maximal bounds
18
SLIDE 19
Performance Evalua5on
- Measured CPU and memory overhead
– Olden and SPEC benchmarks
- Baggy
– Baggy bounds checking as described
- Splay
– Splay tree from previous solu5ons – Standard allocator – Same checks
19
SLIDE 20
Execu5on Time vs. Splay Tree
- 30% for baggy vs. 6x for splay tree on average
0 2 4 6 8 10 12 14 16 18 20 bh bisort em3d perimeter power treeadd tsp bzip2 craoy gap gzip mcf parser twolf vortex average Normalized Execu0on Time Baggy Splay
20
SLIDE 21
Memory Usage vs. Splay Tree
- 7.5% for baggy vs. 100% for splay on average
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 bh bisort em3d health mst perimeter power treeadd tsp bzip2 craoy gap gzip mcf parser twolf vortex average Normalized Peak Memory Baggy Splay
21
SLIDE 22
Apache Throughput
0 1000 2000 3000 4000 5000 6000 1 2 3 4 5 6 Requests per second Concurrency Base Baggy
- 8% throughput decrease with saturated CPU
22
SLIDE 23
Effec5veness
- Evaluated using buffer overflow suite
[Wilander and Kamkar]
- Blocked 17 out of 18 aEacks
- Missed overflow between structure fields
23
SLIDE 24
Baggy bounds on x64
- Baggy bounds can fit inside pointers
Avoid memory lookup en5rely: mov rax, p ; copy pointer shr rax, 38 ; shio tag to %al
24
SLIDE 25
x64 Out‐of‐bounds pointers
25
- Adjust pointer by offset in spare bits
- Greatly increases out‐of‐bounds range
SLIDE 26
Conclusions
- Baggy Bounds Checking provides prac5cal
protec5on from bounds errors in C\C++
- Works on unmodified programs
- Preserves binary compa5bility
- Good performance
– Low CPU overhead (30% average) – Low memory overhead (7.5% average)
- Can protect systems in produc5on runs
26