FREEGUARD A Faster Secure Heap Allocator Sam Silvestro

FREEGUARD: A Faster Secure Heap Allocator Sam Silvestro, Hongyu Liu, Corey Crosser, Zhiqiang Lin*, Tongping Liu University of Texas at San Antonio * University of Texas at Dallas

Memory Security of C/C++ Programs • Stack security • Heap security 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 2

Memory Security of C/C++ Programs • Stack security • Heap security 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 3

Common Heap Vulnerabilities • Buffer over-read – Information leakage • e. g. , Heartbleed • Use-after-free • Buffer overflow • Double / invalid free – Unexpected results, program crash, hijacked control flow 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 4

Heap Vulnerabilities Reported in NIST Database Heap Vulnerabilities Heap Over-reads Heap Over-writes Occurrences (#) Use-after-frees Invalid-frees Double-frees 264 35 33 125 673 Many vulnerabilities were reported just in the past yea 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 5

Defending Heap Vulnerabilities • Detect bugs with automated tools, e. g. coverity, asan – Overhead issue, completeness, false positives • Rewrite code using a safer language, e. g. java – Huge amount of effort and performance issue • Prevent code execution – Can’t handle return-to-libc or ROP attack • Sanity check on execution flow, e. g. CFI – Balance between performance and effectiveness • Increase the difficulty of attacks, e. g. 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 6

Defending Heap Vulnerabilities • Detect bugs with automated tools, e. g. coverity, asan – Overhead issue, completeness, false positives • Rewrite code using a safer language, e. g. java – Huge amount of effort and performance issue • Prevent code execution – Can’t handle return-to-libc or ROP attack • Sanity check on execution flow, e. g. CFI – Balance between performance and effectiveness • Increase the difficulty of attacks, e. g. 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 7

Default Linux Allocator • Designed to perform well malloc_sta te – Bump pointers + freelists – Not designed for security purposes ⋮ top • Prepends metadata before actual objects • Provides no randomization ⋮ – Result: easy to determine next object to be allocated • Poor handling of double/invalid frees unused allocate d header free header Heap segment prev size 16 cur size 32 allocated space prev size cur size free space �������� �� ����� 32 24 �� fd bk An example of Linux allocator’s object metadata placement 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 8

Existing Secure Allocators: Open. BSD and Die. Harder • Both are BIBOP-style secure allocators – “Big Bag of Pages” – Each “bag” of pages holds objects of a specific size class • Both feature randomization related with each size class – Die. Harder = log n bits of entropy – Open. BSD = 2 ~ 10 bits • Both impose high performance overhead – Evaluated runtime overhead: • Open. BSD ≈ 34% • Die. Harder ≈ 88%, up to 10 X – Use bitmaps – Utilize large number of system calls (mmap) – Use the same heap for different threads • May result in significant performance loss for dominant multithreaded apps 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 9

Motivation of Free. Guard Die. Harder Security Open. BSD Free. Guard 2 1 3 4 Linux Performance • Performance-oriented allocators are not secure • Secure allocators are too slow 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 10

FREEGUARD’s BIBOP-style Layout • Acquire large block and divide into multiple heaps • Per-thread sub-heap design • Sub-heaps made up of 16 bags • All bags have same size • Each bag serves a specific size class • Size classes increase by powers-of-two 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 11

FREEGUARD’s BIBOP-style Layout • When one heap is exhausted, the thread utilizes the bag (with the same index) in the next heap • Uniform layout: – Bags have same size – Same number of bags per sub-heap – Same number of subheaps per heap – All quantities are powers of two 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 12

FREEGUARD’s BIBOP-style Layout • Informationcomputable – Given an address: • • Size class Owning thread Starting address Metadata location – Enables constant-time deallocation – Detects all double and invalid frees 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 13

Freelist-based Design • Linked-list maintains deallocated objects • Enables constant-time allocation HEAD Freelist : 1 2 3 4 TAIL • Together, with information-computable layout: 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 14

Summary of Performance Improvements • Unique information-computable design – BIBOP-style layout with metadata in shadow memory • Constant-time allocation and deallocation • Per-thread sub-heap design reduces lock contention • Reduced number of system calls 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 15

Secure Design – Segregated Metadata • BIBOP style can separate metadata with the actual heap • Metadata is placed in a separate area, preventing metadata-based attacks Linux Allocator 2/25/2021 prev size 16 cur size 32 allocated space prev size 32 cur size free space ���� �� ���� 24�� bk fd The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 16

Secure Design – Randomization • Four-way randomization: increase attack complexity – Each per-thread/per-bag pair has 4 freelists & 4 bump pointers – On allocation, choose one-of-four freelists and possibly from bump pointers – If empty, use the bump pointer with the same index – Some chance we fall back to bump pointer, even if freelist is nonrand() = 14 empty Heap 0 Heap 1 Heap 2 Heap 3 Metadata: Heap Data: Freelist 0 Bump Ptr 0 Freelist 1 Bump Ptr 1 Freelist 2 Freelist 3 2/25/2021 14 MOD 4 = 2 Bump Ptr 3 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 17

Secure Design – Guard Pages • Guard pages have all permission bits turned off • Static guard pages – Placed at end of every bag • Random guard pages – Distributed throughout bag – Default proportion: 10% of each bag – Helps prevent heap spraying, buffer overflow attacks Randomized Guard Pages Static Guard Pages �� Allocate d Free Guard Page SEGFAULT Bag n 2/25/2021 Bag n+1 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 18

Secure Design – Canaries • Canary values with neighbor checking – Checks canary values of freed object’s neighbors – Helps the timely detection of overflows – Skips neighbor if not in-use or inside guard pages Free ( ) Heap objects: Guard Page Check 2/25/2021 No Check The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 19

Handling Large Objects • Objects >512 KB classified as large objects – Allocated separately using mmap, which is similar to Die. Harder, but different from Open. BSD – After deallocation, memory is returned to OS using munmap, helping to prevent use-after-free attacks – Hashtable is used to track the size of each object – Object is placed at the end of the block to help detect overflows Guard Page Start 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 20

Security Feature Comparison Security Feature Linux Die. Harder Open. BSD Free. Guar d Fully-segregated metadata ✓ ✓ ✓ Randomized allocation ✓ ✓ Guard pages ✓ Check overflows on free Over-provisioned allocation • ✓ ✓ indicates the allocator has this feature Detects double/invalid ✓ ✓ indicates the implementation has some weakness frees Free. Guard provides feature-set comparable to Die. Harder and Open. BSD, but: – Free. Guard and Open. BSD do not support heap over-provisioning – Free. Guard has a lower randomization entropy • Free. Guard can detect all double and invalid frees; Open. BSD detects double frees with very low probability, while Die. Harder does not report either • Free. Guard and Die. Harder better prevent use-after-free of large objects over Open. BSD 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 21

Performance Evaluation Open. BSD 10. 7 4. 2 6. 0 Free. Guard 3. 0 1. 9 Normalized Performance 1. 4 1. 2 1 0. 8 0. 6 0. 4 0. 2 ch bo ole dy s tra ca ck nn ea de l d fa up ce si m flu fe id rr an et im a f r st eq te re am min cl e sw ust ap er tio ns x 2 64 Ag Ap et ac h M Fir e em ef ca ox ch M ed y. S Q Pb L zi p Pf 2 sc a SQ n Li te AV ER AG E 0 ks • < 2% overhead, on average (arithmetic mean) • Firefox + FG ≈ 5% faster 1. 6 Die. Harder ac – PARSEC – 8 realworld Linux bl • 19 applications evaluated All values normalized to performance of default Linux allocator 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 22

Conclusion • FREEGUARD is a faster secure heap allocator – Combines the benefits of both BIBOP-style and sequential allocators – Layout enables information-computable property – Reduced system calls counts – Implements multiple proven security features • FREEGUARD provides secure memory allocation with < 2% overhead 2/25/2021 The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 23