Shimin Chen (LBA Reading Group Presentation)

1. Comprehensively and Efficiently Protecting the Heap- Kharbutli, Jiang, Solihin, Venkataramani, Prvulovic, ASPLOS 2006 Shimin Chen (LBA Reading Group Presentation)

2. 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

3. 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

4. Heap Attacks’ Three Stages • Bug exploitation stage: e.g. buffer overflow • Activation stage: e.g.corrupted meta-data causes heap lib to overwrite app critical data or function pointers • Seized stage: e.g.program behavior is altered • More ways to carry out later stages than earlier stages

5. Heap Protection • Bug exploitation stage • Activation stage • 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

6. Solution: Heap Server A separate process manages app heaps: • Meta data in separate address space • Layout obfuscation of heap data

7. Outline • Heap Attacks • Heap Server • Evaluation • Conclusion

8. 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;

9. Forward Consolidation Attack:(2) Buffer Overflow B->fd->bk = B->bk; B->bk->fd = B->fd;

10. Forward Consolidation Attack:(3) Activation: B removed from free list B->fd->bk = B->bk; B->bk->fd = B->fd;

11. Outline • Heap Attacks • Heap Server • Evaluation • Conclusion

12. Heap Server Protection Mechanisms • Store meta-data separately from data • New bitmapped meta-data organization • Store meta-data in a separate process • Inter-process messaging • Obfuscate heap layout

13. 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

14. non-blocking free • batch frees • book-keep in background Pre-allocation of frequent sizes Traditional Unoptimized Non-blocking Heap Server

15. 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

16. Outline • Heap Attacks • Heap Server • Evaluation • Conclusion

17. 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

19. 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

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

21. Execution Time Overheads

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

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

24. Backup Slides

25. 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