check point (a global provider of IT security solutions) released several days ago the introduction of the safety mechanism "Safe-Linking", which makes it difficult to create exploits that manipulate the definition or change of pointers to allocated buffers when making a malloc call.
The new «Safe-Linking» mechanism does not completely block the possibility of exploiting vulnerabilities, but with minimal overhead complicates the creation of certain categories of exploitsAs in addition to the exploited buffer overflow, it is necessary to find another vulnerability that causes information about the location of the heap in memory.
Safe-Linking implementation patches were prepared for Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) and Google TCMalloc, as well as a proposal to modernize protection in Chromium (since 2012 Chromium has already been integrated with solutions to the same problem) MaskPtr protection technique, but Checkpoint's solution shows better performance).
The proposed patches have already been approved for delivery in the August release of Glibc 3.32 and Safe-Linking will be enabled by default. In uClibc-NG, secure link support was included in version 1.0.33 and is enabled by default. In gperftools (old tcmalloc) the changes are accepted, but will be offered as an option in a future release.
TCMalloc developers refused to accept the change, cwith strong performance success and the need to add advanced tests to regularly verify that everything is working properly.
Tests carried out by Check point engineers showed that the Safe-Linking method does not lead to additional memory consumption and the performance when performing heap operations on average decreases only by 0.02%, and in the worst case by 1.5%
Enabling Safe-Linking leads to the execution of 2-3 additional assembler instructions with each call to free () and 3-4 instructions when calling malloc (). Initialization and generation of random values is not required.
Safe-Linking can be used not only to increase safety of various heap implementations, sino also to add integrity checks to any data structure that uses a list of individually linked pointers located next to the buffers.
The method it is very simple to implement and only requires adding a macro and apply it to the pointers to the next block of the code (for example, for Glibc only a few lines are changed in the code).
The essence of the method is to apply random data from the ASLR address randomization mechanism (mmap_base) to protect individually linked lists such as Fast-Bins and TCache. Before applying the pointer value to the next item in the list, mask conversion and alignment check is performed along the edge of the memory page. The pointer is replaced with 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 this pointer is stored.
When used in the ASLR (Address Space Layout Randomization) system, some of the L bits with the base address of the heap contain random values that are used as a key to encode P (they are extracted by a shift operation of 12 bits for 4096-byte pages).
Such manipulation reduces the risk of capturing a pointer in an exploit, Since the pointer is not stored in its original form, and to replace it, you need to know information about the location of the heap.
The method is effective in protecting against attacks that use partial pointer redefinition (low byte shift), complete rewrite of pointers (redirect to the attacker's code) and change the position of the list in a non-aligned direction.
As an example, it is shown that the use of Safe-Linking in malloc would block the exploitation of the vulnerability CVE-2020-6007 recently discovered by the same researchers in the Philips Hue Bridge smart backlight caused by the buffer overflow and allowing to control the device.
Source: https://research.checkpoint.com