|
120
|
1 ========================
|
|
|
2 Scudo Hardened Allocator
|
|
|
3 ========================
|
|
|
4
|
|
|
5 .. contents::
|
|
|
6 :local:
|
|
|
7 :depth: 1
|
|
|
8
|
|
|
9 Introduction
|
|
|
10 ============
|
|
|
11
|
|
|
12 The Scudo Hardened Allocator is a user-mode allocator based on LLVM Sanitizer's
|
|
|
13 CombinedAllocator, which aims at providing additional mitigations against heap
|
|
|
14 based vulnerabilities, while maintaining good performance.
|
|
|
15
|
|
|
16 The name "Scudo" has been retained from the initial implementation (Escudo
|
|
|
17 meaning Shield in Spanish and Portuguese).
|
|
|
18
|
|
|
19 Design
|
|
|
20 ======
|
|
|
21
|
|
|
22 Chunk Header
|
|
|
23 ------------
|
|
|
24 Every chunk of heap memory will be preceded by a chunk header. This has two
|
|
|
25 purposes, the first one being to store various information about the chunk,
|
|
|
26 the second one being to detect potential heap overflows. In order to achieve
|
|
|
27 this, the header will be checksumed, involving the pointer to the chunk itself
|
|
|
28 and a global secret. Any corruption of the header will be detected when said
|
|
|
29 header is accessed, and the process terminated.
|
|
|
30
|
|
|
31 The following information is stored in the header:
|
|
|
32
|
|
|
33 - the 16-bit checksum;
|
|
|
34 - the user requested size for that chunk, which is necessary for reallocation
|
|
|
35 purposes;
|
|
|
36 - the state of the chunk (available, allocated or quarantined);
|
|
|
37 - the allocation type (malloc, new, new[] or memalign), to detect potential
|
|
|
38 mismatches in the allocation APIs used;
|
|
|
39 - whether or not the chunk is offseted (ie: if the chunk beginning is different
|
|
|
40 than the backend allocation beginning, which is most often the case with some
|
|
|
41 aligned allocations);
|
|
|
42 - the associated offset;
|
|
|
43 - a 16-bit salt.
|
|
|
44
|
|
|
45 On x64, which is currently the only architecture supported, the header fits
|
|
|
46 within 16-bytes, which works nicely with the minimum alignment requirements.
|
|
|
47
|
|
|
48 The checksum is computed as a CRC32 (requiring the SSE 4.2 instruction set)
|
|
|
49 of the global secret, the chunk pointer itself, and the 16 bytes of header with
|
|
|
50 the checksum field zeroed out.
|
|
|
51
|
|
|
52 The header is atomically loaded and stored to prevent races (this requires
|
|
|
53 platform support such as the cmpxchg16b instruction). This is important as two
|
|
|
54 consecutive chunks could belong to different threads. We also want to avoid
|
|
|
55 any type of double fetches of information located in the header, and use local
|
|
|
56 copies of the header for this purpose.
|
|
|
57
|
|
|
58 Delayed Freelist
|
|
|
59 -----------------
|
|
|
60 A delayed freelist allows us to not return a chunk directly to the backend, but
|
|
|
61 to keep it aside for a while. Once a criterion is met, the delayed freelist is
|
|
|
62 emptied, and the quarantined chunks are returned to the backend. This helps
|
|
|
63 mitigate use-after-free vulnerabilities by reducing the determinism of the
|
|
|
64 allocation and deallocation patterns.
|
|
|
65
|
|
|
66 This feature is using the Sanitizer's Quarantine as its base, and the amount of
|
|
|
67 memory that it can hold is configurable by the user (see the Options section
|
|
|
68 below).
|
|
|
69
|
|
|
70 Randomness
|
|
|
71 ----------
|
|
|
72 It is important for the allocator to not make use of fixed addresses. We use
|
|
|
73 the dynamic base option for the SizeClassAllocator, allowing us to benefit
|
|
|
74 from the randomness of mmap.
|
|
|
75
|
|
|
76 Usage
|
|
|
77 =====
|
|
|
78
|
|
|
79 Library
|
|
|
80 -------
|
|
|
81 The allocator static library can be built from the LLVM build tree thanks to
|
|
|
82 the ``scudo`` CMake rule. The associated tests can be exercised thanks to the
|
|
|
83 ``check-scudo`` CMake rule.
|
|
|
84
|
|
|
85 Linking the static library to your project can require the use of the
|
|
|
86 ``whole-archive`` linker flag (or equivalent), depending on your linker.
|
|
|
87 Additional flags might also be necessary.
|
|
|
88
|
|
|
89 Your linked binary should now make use of the Scudo allocation and deallocation
|
|
|
90 functions.
|
|
|
91
|
|
|
92 You may also build Scudo like this:
|
|
|
93
|
|
|
94 .. code::
|
|
|
95
|
|
|
96 cd $LLVM/projects/compiler-rt/lib
|
|
|
97 clang++ -fPIC -std=c++11 -msse4.2 -mcx16 -O2 -I. scudo/*.cpp \
|
|
|
98 $(\ls sanitizer_common/*.{cc,S} | grep -v "sanitizer_termination\|sanitizer_common_nolibc") \
|
|
|
99 -shared -o scudo-allocator.so -lpthread
|
|
|
100
|
|
|
101 and then use it with existing binaries as follows:
|
|
|
102
|
|
|
103 .. code::
|
|
|
104
|
|
|
105 LD_PRELOAD=`pwd`/scudo-allocator.so ./a.out
|
|
|
106
|
|
|
107 Options
|
|
|
108 -------
|
|
|
109 Several aspects of the allocator can be configured through the following ways:
|
|
|
110
|
|
|
111 - by defining a ``__scudo_default_options`` function in one's program that
|
|
|
112 returns the options string to be parsed. Said function must have the following
|
|
|
113 prototype: ``extern "C" const char* __scudo_default_options()``.
|
|
|
114
|
|
|
115 - through the environment variable SCUDO_OPTIONS, containing the options string
|
|
|
116 to be parsed. Options defined this way will override any definition made
|
|
|
117 through ``__scudo_default_options``;
|
|
|
118
|
|
|
119 The options string follows a syntax similar to ASan, where distinct options
|
|
|
120 can be assigned in the same string, separated by colons.
|
|
|
121
|
|
|
122 For example, using the environment variable:
|
|
|
123
|
|
|
124 .. code::
|
|
|
125
|
|
|
126 SCUDO_OPTIONS="DeleteSizeMismatch=1:QuarantineSizeMb=16" ./a.out
|
|
|
127
|
|
|
128 Or using the function:
|
|
|
129
|
|
|
130 .. code::
|
|
|
131
|
|
|
132 extern "C" const char *__scudo_default_options() {
|
|
|
133 return "DeleteSizeMismatch=1:QuarantineSizeMb=16";
|
|
|
134 }
|
|
|
135
|
|
|
136
|
|
|
137 The following options are available:
|
|
|
138
|
|
|
139 +-----------------------------+---------+------------------------------------------------+
|
|
|
140 | Option | Default | Description |
|
|
|
141 +-----------------------------+---------+------------------------------------------------+
|
|
|
142 | QuarantineSizeMb | 64 | The size (in Mb) of quarantine used to delay |
|
|
|
143 | | | the actual deallocation of chunks. Lower value |
|
|
|
144 | | | may reduce memory usage but decrease the |
|
|
|
145 | | | effectiveness of the mitigation; a negative |
|
|
|
146 | | | value will fallback to a default of 64Mb. |
|
|
|
147 +-----------------------------+---------+------------------------------------------------+
|
|
|
148 | ThreadLocalQuarantineSizeKb | 1024 | The size (in Kb) of per-thread cache use to |
|
|
|
149 | | | offload the global quarantine. Lower value may |
|
|
|
150 | | | reduce memory usage but might increase |
|
|
|
151 | | | contention on the global quarantine. |
|
|
|
152 +-----------------------------+---------+------------------------------------------------+
|
|
|
153 | DeallocationTypeMismatch | true | Whether or not we report errors on |
|
|
|
154 | | | malloc/delete, new/free, new/delete[], etc. |
|
|
|
155 +-----------------------------+---------+------------------------------------------------+
|
|
|
156 | DeleteSizeMismatch | true | Whether or not we report errors on mismatch |
|
|
|
157 | | | between sizes of new and delete. |
|
|
|
158 +-----------------------------+---------+------------------------------------------------+
|
|
|
159 | ZeroContents | false | Whether or not we zero chunk contents on |
|
|
|
160 | | | allocation and deallocation. |
|
|
|
161 +-----------------------------+---------+------------------------------------------------+
|
|
|
162
|
|
|
163 Allocator related common Sanitizer options can also be passed through Scudo
|
|
|
164 options, such as ``allocator_may_return_null``. A detailed list including those
|
|
|
165 can be found here:
|
|
|
166 https://github.com/google/sanitizers/wiki/SanitizerCommonFlags.
|
|
|
167
|
