1 / 25

Comprehensive and Efficient Protection Against Heap Attacks

This paper explores innovative strategies to protect heap memory from security vulnerabilities that can be exploited through manipulation of control flow and critical data. It critically analyzes current heap management schemes and introduces the concept of a Heap Server, which segregates application meta-data from heap data to enhance security. The proposed solutions include layout obfuscation and inter-process messaging. Evaluation metrics demonstrate the efficiency and effectiveness of these strategies, highlighting their ability to prevent heap-related attacks while minimizing overhead.

onawa
Télécharger la présentation

Comprehensive and Efficient Protection Against Heap Attacks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

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

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

  20. Execution Time Overheads

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

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

  23. Backup Slides

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

More Related