Checkpoint company Safe-Linking protection mechanism, which makes it more difficult to create exploits that manipulate the definition or change of pointers to buffers allocated during a call to malloc. Safe-Linking does not completely block the possibility of exploiting vulnerabilities, but with minimal overhead, it significantly complicates the creation of certain categories of exploits, since in addition to the exploited buffer overflow, it is necessary to find one more vulnerability that leaks information about the location of the heap in memory.
Safe-Linking patches have been prepared for Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) and Google TCMalloc, and have also been proposed for upgrading protection in Chromium (in
Chromium already has a built-in MaskPtr protection technique aimed at solving the same problem since 2012, but Checkpoint's solution shows better performance).
Proposed patches already approved for delivery in the August release and Safe-Linking will be enabled by default. uClibc-NG supports Safe-Linking included in release 1.0.33 and enabled by default. In gperftools (old tcmalloc) changes , but will be offered as an option in a future release.
Developers (new tcmalloc) refused to accept , citing severe performance degradation and the need to add extensive tests to regularly check that everything is working as expected. Testing by Checkpoint engineers showed that the Safe-Linking method does not lead to additional memory consumption, and the performance when performing heap operations decreases by only 0.02% on average, and in the worst case by 1.5% (for comparison, the overhead costs in the method used in Chromium rated as "less than 2%"). Inclusion
Safe-Linking results in 2-3 additional assembler instructions being executed on every call to free() and 3-4 instructions on calling malloc(). Running the initialization and randomization stages is not required.
Safe-Linking can be used not only to improve the security of various heap implementations, but also to add integrity controls to any data structures that use singly linked lists of pointers placed next to the buffers themselves. The method is very simple to implement and requires only adding one macro and applying it to pointers to the next block in the code (for example, for Glibc just a few lines of code). The method comes 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 to use random data from the ASLR address randomization mechanism (mmap_base) to protect singly linked lists such as Fast-Bins and TCache. Before being applied to the value of a pointer to the next element in the list, a mask conversion is performed and alignment is checked on the memory page boundary. The pointer is replaced by the result of the operation "(L >> PAGE_SHIFT) XOR (P)", where P is the value of the pointer and L is the location in memory where the pointer is stored.
When used in the system (Address Space Layout Randomization) part of the L bits with the base address of the heap contains random values ββthat are used as a key for encoding P (extracted by a shift operation by 12 bits for 4096-byte pages). This manipulation reduces the risk of a pointer being captured in an exploit, since the pointer is not stored in its original form and requires knowledge of the heap location to replace it. In addition, the patch code also contains an additional block alignment check, which does not allow the attacker to replace the pointer with an unaligned value and requires knowledge of the number of bits on which the alignment is performed, which on 64-bit systems additionally allows blocking 15 out of 16 attack attempts that do not take alignment into account .
The method is effective against attacks that use partial rewriting of pointers (changing the low bytes), complete rewriting of pointers (redirecting to the attacker's code), and changing the position of the list at an unaligned address. As an example, it is shown that the use of Safe-Linking in malloc would allow blocking the operation recently by the same vulnerability researchers in the Philips Hue Bridge smart backlight, caused by a buffer overflow and allowing you to take control of the device.
Source: opennet.ru