Checkpoint запропонував техніку захисту Safe-Linking, що ускладнює експлуатацію вразливостей

Компанія 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, викликаному переповненням буфера і дозволяє отримати контроль над пристроєм.

Джерело: opennet.ru