Патчи с реализацией Safe-Linking подготовлены для Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) и Google TCMalloc, а также предложены для модернизации защиты в Chromium (в Chromium с 2012 году уже встроена нацеленная на решений той же проблемы техника защиты MaskPtr, но решение от Checkpoint демонстрирует более высокую производительность). Предложенные патчи уже одобрены для поставки в августовском выпуске Glibc 3.32 и применение Safe-Linking будет включено по умолчанию. В uClibc-NG поддержка Safe-Linking вошла в состав выпуска 1.0.33 и включена по умолчанию. В gperftools (старый tcmalloc) изменения приняты, но будут предложены в одном из будущих выпусков в качестве опции.
Разработчики TCMalloc (новый tcmalloc) отказались принять изменение, сославшись на сильное снижение производительности и необходимость добавления расширенных тестов для регулярной проверки того, что всё работает должным образом. Тестирование же инженерами Checkpoint показало что метод Safe-Linking не приводит к дополнительному расходу памяти, а производительность при выполнении операций с кучей в среднем снижается лишь на 0.02%, а при наихудшем стечении обстоятельств на 1.5% (для сравнения накладные расходы в применяемом в Chromium методе оцениваются как «меньше 2%»). Включение Safe-Linking приводит к выполнению 2-3 дополнительных ассемблерных инструкций при каждом вызове free() и 3-4 инструкций при вызове malloc(). Запуск стадий инициализации и генерации случайных значений не требуется.
Safe-Linking может применяться не только для повышения безопасности различных реализаций кучи (heap), но и для добавления средств контроля целостности в любые структуры данных, в которых применяются односвязные списки указателей, размещаемые рядом с самими буферами. Метод очень прост в реализации и требует лишь добавления одного макроса и его применения к указателям на следующий блок в коде (например, для Glibc изменяется всего несколько строк в коде). Метод сводится к следующим изменениям:
+#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); ...
Суть метода в применении случайных данных от механизма рандомизации адресов ASLR (mmap_base) для защиты односвязных списков, таких как Fast-Bins и TCache. Перед применением к значению указателя на следующий элемент в списке применяется преобразование по маске и проверка выравнивания по границе страницы памяти, т.е. указатель заменяется на результат операции «(L ›› PAGE_SHIFT) XOR (P)», где P — значение указателя, а L — местоположение в памяти, где хранится этот указатель.
При использовании в системе ASLR (Address Space Layout Randomization) часть битов L с базовым адресом кучи содержат случайные значения, которые используется как ключ для кодирования P (извлекаются операцией сдвига на 12 бит для 4096-байтовых страниц). Подобная манипуляция снижает риск захвата указателя в эксплоите, так как указатель не хранится в исходном виде и для его замены требуется знать сведения о размещении кучи. Кроме того, в коде патча также присутствует дополнительная проверка выравнивания блока, которая не позволяет атакующему заменить указатель на невыровненное значение и требует знания числа бит на которые произведено выравнивание, что на 64-разрядных системах дополнительно позволяет блокировать 15 из 16 попыток атак.
Метод эффективен для защиты от атак, в которых используются частичное переопределение указателей (изменение младших байтов), полная перезапись указателей (перенаправление на код атакующего) и смена позиции списка по невыровненному адресу. В качестве примера показано, что применение Safe-Linking в malloc позволило бы блокировать эксплуатацию недавно выявленной теми же исследователями уязвимости CVE-2020-6007 в умной подсветке Philips Hue Bridge, вызванной переполнением буфера и позволяющей получить контроль за устройством.
Источник: http://www.opennet.ru/opennews/art.shtml?num=53013