Checkpoint Company The Safe-Linking protection mechanism complicates the creation of exploits that manipulate the definition or modification of pointers to buffers allocated during the malloc call. Safe-Linking does not completely block the possibility of exploiting vulnerabilities, but it significantly complicates the creation of some categories of exploits with minimal overhead, as besides the exploited buffer overflow, another vulnerability must be found that leaks information about the heap placement in memory.
Patches implementing Safe-Linking have been prepared for Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc), and Google TCMalloc, as well as proposed for enhancing protection in Chromium (in
Chromium, since 2012, a protection technique called MaskPtr aimed at solving the same problem has been integrated, but Checkpoint's solution demonstrates higher performance).
The proposed patches have already been approved for delivery in the August release and the application of Safe-Linking will be included by default. In uClibc-NG, support for Safe-Linking is included in release 1.0.33 and enabled by default. In gperftools (old tcmalloc), changes , but will be offered in one of the future releases as an option.
Developers (new tcmalloc) refused to accept , citing a significant drop in performance and the need to add extensive tests to regularly check that everything functions properly. Testing by Checkpoint engineers showed that the Safe-Linking method does not lead to additional memory overhead, while performance when performing heap operations decreases on average by only 0.02%, and in the worst-case scenario by 1.5% (for comparison, the overhead in the method used in Chromium is estimated to be "less than 2%"). The inclusion
of Safe-Linking results in the execution of 2-3 additional assembly instructions with each free() call and 3-4 instructions with malloc() calls. Running the initialization and random value generation stages is not required.
Safe-Linking can be applied not only to enhance the security of various heap implementations but also to add integrity checking mechanisms to any data structures that utilize singly linked lists of pointers placed next to the buffers themselves. The method is straightforward to implement and requires only the addition of a single macro and its application to the pointers of the next block in the code (for example, for Glibc just a few lines in the code). The method boils down to the following changes:
+#define PROTECT_PTR(pos, ptr) \
+ ((__typeof (ptr)) ((((size_t) pos) >> 12) ^ ((size_t) ptr)))
+#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)
— nextp = p->fd;
+ nextp = REVEAL_PTR (p->fd);
…
The essence of the method is in applying random data from the ASLR (Address Space Layout Randomization) mechanism (mmap_base) to protect singly linked lists, such as Fast-Bins and TCache. Before applying to the pointer value of the next element in the list, a masking transformation and alignment check against the memory page boundary are performed. The pointer is replaced with the result of the operation "(L >> PAGE_SHIFT) XOR (P)", where P is the pointer value, and L is the memory location where this pointer is stored.
When used in the system (Address Space Layout Randomization) part of the bits L with the base address of the heap contains random values, which are used as a key for encoding P (extracted by shifting 12 bits for 4096-byte pages). Such manipulation reduces the risk of pointer hijacking in exploits, as the pointer is not stored in its original form and requires knowledge of the heap layout for replacement. Additionally, the patch code also includes an extra block alignment check that prevents an attacker from replacing the pointer with an unaligned value and requires knowledge of the number of bits used for alignment, which on 64-bit systems also allows blocking 15 out of 16 attack attempts that do not consider alignment.
The method is effective for protecting against attacks that use partial pointer overwriting (changing the lower bytes), full pointer rewriting (redirecting to the attacker's code), and changing the list position at an unaligned address. For example, it has been shown that applying Safe-Linking in malloc could block the exploitation of recent the same researchers found vulnerabilities in the Philips Hue Bridge smart lighting system, caused by a buffer overflow, allowing control over the device.
Source: opennet.ru
