Sam Silvestro Hongyu Liu Corey Crosser Zhiqiang Lin Tongping Liu University of Texas at San Antonio University of Texas at Dallas Common Heap Vulnerabilities Buffer overread Information leakage ID: 758528
Download Presentation The PPT/PDF document "F REE G UARD : A Faster Secure Heap All..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
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 DallasSlide2
Common Heap VulnerabilitiesBuffer over-read
Information leakage
e.g.,
HeartbleedUse-after-freeBuffer overflowDouble / invalid freeUnexpected results, program crash, hijacked control flowSlide3
Designed to perform wellBump pointers + freelists
Not designed for security
purposes
Prepends metadata before actual objectsProvides no randomizationResult: easy to determine when an object will be allocatedPoor handling of double/invalid frees
allocated
header
free
header
malloc_state
⋮
top
⋮
Heap segment
unused
unused
allocated
header
allocated
header
free
header
malloc_state
⋮
top
⋮
Heap segment
An example of Linux allocator’s object metadata placement
prev
size
16
cur size
32
allocated space
prev
size
32
cur size
24
free space
💣💣💣💣
💣
fd
bk
💣💣💣💣
💣
💣💣💣💣💣💣
Default Linux AllocatorSlide4
Existing Secure Allocators: OpenBSD and DieHarder
Both are BIBOP-style secure allocators
“Big Bag of Pages”
Each “bag” of pages holds objects of a specific size classBoth feature randomizationDieHarder = log n bits of entropyOpenBSD =
2 ~ 10 bitsBoth impose high performance overheadEvaluated runtime overhead:OpenBSD ≈ 34%
DieHarder ≈ 88%, up to 10X Use bitmapsUtilize many more system calls (mmap
)Use the same heap for different threadsMay result in significant performance loss for dominant multithreaded appsSlide5
Motivation of FreeGuard
Performance-oriented allocators are not secure
Secure allocators are too slow
Performance
Security
FreeGuard
OpenBSD
DieHarder
Linux
1
2
3
4Slide6
FREEGUARD’s BIBOP-style Layout
Acquire large block and divide into multiple heaps
Per-thread sub-heap design
Sub-heaps made up of 16 bagsAll bags have same sizeEach bag serves a specific size classSize classes increase by powers-of-twoSlide7
F
REE
G
UARD’s BIBOP-style LayoutWhen one heap is
exhausted, the thread utilizes the bag (with the same index) in the next heapUniform layout:Bags have same sizeSame number of bags per sub-heapSame number of sub-heaps per heap
All quantities are powers of twoSlide8
FREEGUARD’s BIBOP-style Layout
Information-computable
Given an address:
Size classOwning threadStarting addressMetadata location
Enables constant-time deallocationDetects all double and invalid freesSlide9
Freelist-based Design
Linked-list maintains
deallocated
objectsEnables constant-time allocation
1Freelist
:
HEAD
2
3
4
Together, with information-computable layout:
TAILSlide10
Summary of Performance Improvements
Unique information-computable design
BIBOP-style layout with metadata in shadow memory
Constant-time allocation and deallocationPer-thread sub-heap design reduces lock contentionReduced number of system callsSlide11
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
prev
size
16
cur size
32
allocated space
prev
size
32
cur size
24
free space
fd
bk
💣💣💣💣
💣
💣💣
💣
💣💣
💣
💣💣Slide12
Secure Design – Randomization
Four-way
randomization: increase attack complexity
Each per-thread/per-bag pair has 4 freelists & 4 bump pointersOn allocation, choose one-of-four freelists and possibly from bump pointersIf empty, use the bump pointer with the same indexSome chance we fall back to bump pointer, even if freelist
is non-empty
Metadata:
Freelist 0
Freelist 1
Freelist 2
Freelist
3
Heap 0
Heap 1
Heap 2
Heap Data:
Bump
Ptr
0
Bump
Ptr
1
Bump
Ptr
2
Bump
Ptr
3
Heap 3
rand()
= 14
14 MOD 4 =
2Slide13
Secure Design – Guard Pages
Guard pages have all permission bits turned off
Static guard pages
Placed at end of every bagRandom guard pages
Distributed throughout bagDefault proportion: 10% of each bagHelps prevent heap spraying, buffer overflow attacks
Allocated
Free
Bag
n
Static Guard Pages
Random Guard Pages
Guard Page
💣
Bag
n
+1
SEGFAULTSlide14
Secure Design – Canaries
Canary values with neighbor checking
Checks canary values of freed object’s neighbors
Helps the timely detection of overflowsSkips neighbor if not in-use or inside guard pages
Guard Page
Free ( )
Check
Check
No
Check
Check
Check
Heap objects:Slide15
Handling Large Objects
Objects >512KB classified as large objects
Allocated separately using mmap, which is similar to DieHarder, but different from OpenBSD
After deallocation, memory is returned to OS using munmap, helping to prevent use-after-free attacksHashtable is used to track the size of each object Object is placed at the end of the block to help detect overflows
Guard Page
StartSlide16
Security Feature Comparison
FreeGuard provides feature-set comparable to DieHarder
and OpenBSD, but:FreeGuard and OpenBSD do not support heap over-provisioningFreeGuard has a lower randomization entropyFreeGuard can detect all double and invalid frees; OpenBSD detects
double frees with very low probability, while DieHarder does not report eitherFreeGuard and DieHarder better prevent use-after-free of large objects over OpenBSD
✓ indicates the allocator has this feature indicates the implementation has some weakness
Security Feature
LinuxDieHarder
OpenBSD
FreeGuard
Fully-segregated metadata
✓
✓
✓
Randomized
allocation
✓
✓
Guard pages
✓
✓
Check overflows on free
✓
Over-provisioned
allocation
✓
Detects double/invalid frees
✓
✓Slide17
Performance Evaluation
19
applications
evaluated
PARSEC
8 real-world
< 2% overhead,
on average (arithmetic mean)
Firefox + FG ≈ 5% faster
All values normalized to performance of default Linux allocator
10.7
6.0
4.2
3.0
1.9Slide18
ConclusionF
REE
G
UARD is a faster secure heap allocatorCombines the benefits of both BIBOP-style and sequential allocatorsLayout enables information-computable propertyReduced system calls counts
Implements multiple proven security featuresFREEG
UARD provides secure memory allocation
with < 2% overhead