Shimin Chen (LBA Reading Group Presentation)

Comprehensively and Efficiently Protecting the Heap- Kharbutli, Jiang, Solihin, Venkataramani, Prvulovic, ASPLOS 2006

Shimin Chen

(LBA Reading Group Presentation)

Motivation

Security attacks often Modify control flow

e.g. function pointer, return addr, branch target

Modify critical datae.g. cgi-bin path

Focus of this paper: heap attacks

Current Heap Management Schemes

Meta data and app data are interleaved

Not protected from each other Predictability of layout

Unsafe: Vulnerable to meta data corruption Easily figure out critical locations

Heap Attacks’ Three Stages

1. Bug exploitation stage: e.g. buffer overflow

2. Activation stage: e.g. corrupted meta-data causes heap lib to overwrite app critical data or function pointers

3. Seized stage: e.g. program behavior is altered

More ways to carry out later stages than earlier stages

Heap Protection

1. Bug exploitation stage2. Activation stage3. Seized stage

Focus on one or more of the stages Previous schemes focus on stage 2 or 3,

assuming particular steps being carried out by attackse.g. non-executable heap

This paper focuses on stage 1 Protect against corruption

Solution: Heap Server

A separate process manages app heaps:

Meta data in separate address space Layout obfuscation of heap data

Outline

Heap Attacks Heap Server Evaluation Conclusion

Forward Consolidation Attack:(1) Before Attack

• GNU C Library

• Free chunks are in a doubly linked list

• Fd: forward pointer

• Bk: backward pointer

B->fd->bk = B->bk;

B->bk->fd = B->fd;

Forward Consolidation Attack:(2) Buffer Overflow

B->fd->bk = B->bk;

B->bk->fd = B->fd;

Forward Consolidation Attack:(3) Activation: B removed from free list

B->fd->bk = B->bk;

B->bk->fd = B->fd;

Outline

Heap Attacks Heap Server Evaluation Conclusion

Heap Server Protection Mechanisms

1. Store meta-data separately from data New bitmapped meta-data organization

2. Store meta-data in a separate process

Inter-process messaging

3. Obfuscate heap layout

Bitmapped Meta-Data

Efficiency: 2 bits/8 bytes, O(1) A large number of small malloc/free Tree or hash table can be expensive

Chunk size if long enough

Traditional

Unoptimized

Non-blocking

Heap Server

• non-blocking free

• batch frees

• book-keep in background

Pre-allocation of frequent sizes

Obfuscation Address obfuscation

Insert padding between data chunks Random: [0, min(64,

12.5%*chunk_size)] Layout obfuscation

Reduce predictability of chunk ordering Random recycling Skip random number in [0,16] of nodes

on free list

Outline

Heap Attacks Heap Server Evaluation Conclusion

Methodology Machine: 2-way SMP, 2GHz Xeon with HT,

512KB L2, 512MB RDRAM Red Hat 8.0, Kernel 2.4.20 GCC version 3.2, –O3 Benchmarks: SPEC INT 2000, SPEC FP 2000,

and allocation intensive benchmarks

Attack Avoidance

Avoid two real-world attacks WU-ftpd and Sudo

Avoid attacks on synthetic example Buffer overflow beyond padding can

corrupt app data and cause crashes If heap data contains function pointer,

then it is possible to hijack control flow

Benchmark Characteristics

Average heap request size of benchmarks: 2 bytes - 235 bytes.

Execution Time Overheads

NB: non-blocking, BD: batch de-allocation (free), PA: pre-allocation, Prot: protecting pre-allocation data pointers in app space

Impact of Optimizations

Conclusion

Heap server protects heap meta-data Minimal assumptions Low overhead Existing hardware Few code modifications

Backup Slides

Related Work Non-executable heap, tracking info

flow, program shepherding Transparent Runtime Randomization Address Space Layout Randomization Address Obfuscation PointGuard DieHard: similar to Heap Server but in

the same address space