guarder a tunable secure allocator - usenix · guarder: a tunable secure allocator sam silvestro,...

GUARDER: A Tunable Secure Allocator

Sam Silvestro, Hongyu Liu, Tianyi Liu, Zhiqiang Lin*, Tongping Liu

University of Texas at San Antonio * The Ohio State University

The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 8/28/18 2

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


Heap Vulnerabilities Reported in NIST Database

Heap Vulnerabilities Occurrences (#)

Heap Over-reads 125

Heap Over-writes 673

Use-after-frees 264

Invalid-frees 35

Double-frees 33

Many vulnerabilities were reported just in the past year!


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 – Cannot handle return-to-libc or ROP attack

•  Sanity check on execution flow, e.g. CFI •  Secure heap allocator, e.g. randomization


•  Designed to perform well –  Bump pointers + freelists –  Not designed for security purposes

•  Prepends metadata before actual objects •  Provides no randomization

–  Result: easy to determine when an object will be allocated •  Poor 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 Allocator


Existing Secure Allocators: OpenBSD, DieHarder, and FreeGuard

•  Each are BIBOP-style secure allocators –  “Big Bag of Pages” –  Each “bag” of pages holds objects of a specific size class –  Metadata are separated from the actual heap

•  All feature randomization –  DieHarder = log n bits of entropy –  OpenBSD = 2 ~ 10 bits –  FreeGuard = 2 bits

•  Some impose high performance overhead –  OpenBSD ≈ 31% –  DieHarder ≈ 74%, up to 9.2X


Entropy of Existing Secure Allocators

0

2

4

6

8

10

12

14

16B 32B 64B 128B 256B 512B 1KB 2KB 4KB 8KB 16KB 32KB 64KB 128KB 256KB 512KB

Ent

ropy

(bi

ts)

Size Class

DieHarder OpenBSD FreeGuard

1.  Exhibit either low or unstable entropy 2.  Unstable entropy dependent on size class, execution phase, inputs, and applications


DieHarder’s Security Issue

•  Always selects one object randomly, among all available objects – May take extended period before search is successful – Not reliable è unstable entropy

•  Worse: security is bound to its specific design, which is not flexible


Design Purpose

•  Reliable Security – Stable allocation entropy across:

•  Size classes •  Inputs •  Execution phases •  Applications

•  Tunable security – User may specify the bits of entropy – Balances performance budget with security needs


Supplying the Specified Entropy

•  We could use a simple array as the object buffer – 1 out of 256 objects = 8 bits of entropy

•  Challenges with this approach: – How to handle deallocations?

•  How to efficiently find space to reinsert freed objects?

– How to avoid repopulating array after every allocation? •  < 256 objects è < 8 bits of entropy

– How to avoid excessive checking cycles? •  Upon allocations, probability of choosing empty slot


……

Class:256B

Thread1

Class:16B

……

Thread1: Class:16B

Threadm

Heap

……

Alloc Buffer

0" �" �" �" �E+1?1" �" �" �" M"�"

Dealloc Buffer

�"

Filling

Filli

ng

…… Threadm: Class:64B

……

Alloc Buffer

0" �" �" �" �E+1?1" �" �" �" M"�"

Dealloc Buffer

�"

Filling

…… ……

……

Class:32B Class:64B

Filli

ng

Combining Allocation and Deallocation Buffers

•  Provides minimum of E-bits of user-specified entropy –  Every thread has pair of allocation and deallocation buffers per size class –  Allocation buffer holds 2E+1 objects

•  To never fall below half full ensures minimum E bits entropy

–  Allocation buffer is filled from top of heap if no freed objects are available


Tunable Security – Overprovisioning •  Dedicates a portion of heap objects as “never use”

–  Guarder’s default factor = 1/8 –  Thus, each object has 1/8 probability of being excluded from future

use •  Helps thwart buffer overflow •  During allocation buffer filling step:

–  1/8 of objects will be selected randomly for exclusion –  Corresponding slot marked empty –  Remaining 7/8 of non-empty slots will be pulled into allocation buffer

In-use

New

Available

Heap Allocation Buffer

…

Over-prov Skip Filling…


Tunable Security – Custom Guard Pages

•  Guard pages: cannot be accessed –  Helps prevent heap spraying, buffer overflow attacks –  Guarder’s default proportion = 10% –  During buffer filling, the given proportion of pages are marked as

guard pages

Allocated

Free

Bag n

Static Guard Pages Random Guard Pages

Guard Page

💣

Bag n+1

SEGFAULT


Performance Evaluation •  21

applications evaluated –  PARSEC –  8 real-world

•  < 3% overhead, on average (arithmetic mean)

All values normalized to performance of default Linux allocator

10.7 6.0 4.2 3.0 1.9

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

blackscholes bodytrack canneal dedup facesim

ferret fluidanim

ate freqm

ine raytrace stream

cluster sw

aptions vips

x264

Aget

Apache

Firefox M

emcached

MySQ

L Pbzip2 Pfscan SQ

Lite

AVERA

GE

Nor

mal

ized

Run

time

Default DieHarder OpenBSD FreeGuard Guarder Dummy 9.2 6.1 4.2 1.42 3.0 1.4 1.7


Performance Evaluation

Trials DieHarder OpenBSD FreeGuard Guarder

Allocation Average 1.99 3.79 1 1.77

Maximum 93 45 1 131

Deallocation Average 12.40 1 1 1

Maximum 141 1 1 1

– Two reasons why Guarder performs faster •  Avoids use of central lock •  Due to the following design

Data collected with Guarder’s default tunable parameter of 9 bits of entropy.


Security Feature Comparison

•  Guarder provides the most complete feature-set as compared to existing works

•  Provides the strongest guarantee with respect to randomization entropy

✓ indicates the allocator has this feature indicates the implementation has some weakness

Security Feature Linux DieHarder OpenBSD FreeGuard Guarder

Fully-segregated metadata ✓ ✓ ✓ ✓

Randomized allocation ✓ ✓ ✓

Guard pages ✓ ✓ ✓

Check overflows on free ✓ ✓

Over-provisioned allocation ✓ ✓

Detects double/invalid frees ✓ ✓ ✓


Entropy of Secure Allocators

•  Guarder exhibits reliable entropy •  Allows users to specify the entropy (e.g., 9 bits here)

0

2

4

6

8

10

12

14

16B 32B 64B 128B 256B 512B 1KB 2KB 4KB 8KB 16KB 32KB 64KB 128KB 256KB 512KB

Ent

ropy

(bi

ts)

Size Class

DieHarder OpenBSD FreeGuard Guarder


Why Tunable Matters?

•  Values normalized to default settings •  Higher security indicates higher overhead

Figure 3: Performance overhead of secure allocators (and TCMalloc), where all values are normalized to the defaultLinux allocator.

Trials DieHarder OpenBSD FreeGuard GUARDER

Allocation Average 1.99 3.79 1 1.77Maximum 93 45 1 131

Deallocation Average 12.40 1 1 1Maximum 141 1 1 1

Table 3: Number of trials for allocations and deallocations in different allocators.

Entropy (bits) GPR=10%, OPF=1/88 9 10 11 12

1.003 1.000 1.016 1.031 1.047Guard Page Ratio EB=9, OPF=1/82% 5% 10% 20% 50%

0.987 0.990 1.000 1.016 1.046Over-provisioning Factor EB=9, GPR=10%1/32 1/16 1/8 1/4 1/20.998 0.995 1.000 1.001 1.011

Table 4: Performance sensitivity to each parameter,normalized to the default settings of GUARDER.

EB = Entropy Bits, GPR = Guard Page Ratio, OPF =Over-Provisioning Factor

pages, including 2%, 5%, 10%, 20%, and 50%, weresimilarly evaluated. For the 50% ratio, almost everypage (or object with size greater than 4 kilobytes), willbe separated by a guard page. Similarly, a larger ratioof installed guard pages typically implies a larger perfor-mance overhead, due to invoking more mprotect sys-tem calls.

Over-provisioning factor. Different heap over-provisioning factors, including 1/32, 1/16, 1/8, 1/4,and 1/2, were evaluated. In the extreme case of 1/2,half of the heap will not be utilized. This evaluationshows two results: (1) A larger over-provisioning fac-tor will typically imply larger overhead. (2) The perfor-mance impact of over-provisioning is not as large as ex-pected, as over-provisioning will not affect cache utiliza-tion when skipped objects are completely removed fromfuture allocations and deallocations. However, it maycause a much larger performance impact on DieHarder,due to its special design.

5.3 Memory Overhead

We collected the maximum memory consumption for allfive allocators. For server applications, such as MySQLand Memcached, memory consumption was collected viathe VmHWM field of /proc/pid /status file. For otherapplications, memory consumption was collected usingthe maxresident output of the time utility [22].


Comparison of Existing Security Allocators

Performance

Secu

rity OpenBSD

DieHarder(CCS’10)

Linux

1 2

3 4

Guarder

FreeGuard(CCS’17)


Conclusion

•  GUARDER is a tunable secure heap allocator – Tunable security allows users to choose their security based

on their performance budget – Reliable security provides a stable entropy level across size

classes, inputs, execution phases, and applications – The allocation buffer design facilitates other tunable security

features, heap over-provisioning and random guard pages –  Implements greatest feature set compared to other evaluated

allocators •  GUARDER provides reliable, tunable security with < 3%

performance overhead


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

blackscholes bodytrack canneal dedup facesim

ferret fluidanim

ate freqm

ine raytrace stream

cluster sw

aptions vips

x264

Aget

Apache

Firefox M

emcached

MySQ

L Pbzip2 Pfscan SQ

Lite

AVERA

GE

Nor

mal

ized

Run

time

Default DieHarder OpenBSD FreeGuard Guarder Dummy 9.2 6.1 4.2 1.42 3.0 1.4 1.7

Performance

Secu

rity OpenBSD

DieHarder

Linux

1 2

3 4

Guarder

FreeGuard

0

2

4

6

8

10

12

14

Ent

ropy

(bi

ts)

Size Class

DieHarder OpenBSD FreeGuard Guarder

……

Class:256B

Thread1

Class:16B

……

Thread1: Class:16B

Threadm

Heap

……

Alloc Buffer

0" �" �" �" �E+1?1" �" �" �" M"�"

Dealloc Buffer

�"

Filling

Fil

ling

…… Threadm: Class:64B

……

Alloc Buffer

0" �" �" �" �E+1?1" �" �" �" M"�"

Dealloc Buffer

�"

Filling

…… ……

……

Class:32B Class:64B

Fil

ling

Guarder can be downloaded at https://github.com/UTSASRG/Guarder

The work is also supported by Mozilla

guarder a tunable secure allocator - usenix · guarder: a tunable secure allocator sam silvestro,...

Documents