Компания Checkpoint
представила механизм защиты Safe-Linking, позволяющий усложнить создание эксплоитов, манипулирующих определением или изменением указателей на буферы, выделенные при выполнении вызова malloc. Safe-Linking полностью не блокирует возможность эксплуатации уязвимостей, но при минимальных накладных расходах существенно усложняет создание некоторых категорий эксплоитов, так как помимо эксплуатируемого переполнения буфера необходимо найти ещё одну уязвимость, вызывающую утечку сведений о размещении кучи (heap) в памяти.
Патчи с реализацией 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, вызванной переполнением буфера и позволяющей получить контроль над устройством.
Линейный вид
