КПП (глобальний постачальник рішень з ІТ-безпеки) вийшов кілька днів тому вступ механізму безпеки "Безпечне посилання", що ускладнює створення подвигів які маніпулюють визначенням або зміною покажчиків на виділені буфери під час здійснення виклику malloc.
Новий механізм «безпечного зв’язування» не повністю блокує можливість використання вразливостей, але з мінімальними накладними витратами ускладнює створення певних категорій подвигівОскільки на додаток до переповнення буфера, що використовується, необхідно знайти ще одну вразливість, яка спричиняє інформацію про розташування купи в пам'яті.
Підготовлені патчі реалізації безпечного зв’язування для Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) та Google TCMalloc, а також пропозиція щодо модернізації захисту в Chromium (з 2012 р. Chromium вже інтегрований з рішеннями для та сама проблема) Техніка захисту MaskPtr, але рішення Checkpoint демонструє кращу продуктивність).
Запропоновані виправлення вже схвалено для випуску у серпневій версії Glibc 3.32, і Безпечне зв’язування буде ввімкнено за замовчуванням. У uClibc-NG підтримка захищеного посилання була включена у версію 1.0.33 та ввімкнена за замовчуванням. У gperftools (старий tcmalloc) зміни прийняті, але будуть запропоновані як опція в наступному випуску.
Розробники TCMalloc відмовились прийняти зміни, cіз значним успіхом у роботі та необхідністю додавати розширені тести, щоб регулярно перевіряти, чи все працює належним чином.
Випробування, проведені Інженери контрольних пунктів показали, що метод безпечного зв’язування не призводить до додаткового споживання пам’яті а продуктивність при виконанні операцій купи в середньому знижується лише на 0.02%, а в гіршому випадку на 1.5%
Увімкнення безпечного зв’язування призводить до виконання 2-3 додаткових інструкцій асемблера з кожним викликом free () та 3-4 інструкцій при виклику malloc (). Початок ініціалізації та генерація випадкових значень не потрібні.
Безпечне посилання можна використовувати не лише для підвищення безпеки різних реалізацій купи, сino також для додавання перевірок цілісності до будь-якої структури даних що використовує список індивідуально зв’язаних покажчиків, розташованих поруч із буферами.
Метод це дуже просто реалізувати і вимагає лише додавання макросу і застосувати його до покажчиків до наступного блоку коду (наприклад, для Glibc у коді змінено лише кілька рядків).
Суть методу полягає у застосуванні випадкових даних із механізму рандомізації адрес ASLR (mmap_base) для захисту індивідуально пов’язаних списків, таких як Fast-Bins та TCache. Перш ніж застосовувати значення вказівника до наступного елемента у списку, перетворення маски та перевірка вирівнювання виконуються по краю сторінки пам'яті. Покажчик замінюється результатом операції "(L >> PAGE_SHIFT) XOR (P)", де P - значення покажчика, а L - місце в пам'яті, де цей покажчик зберігається.
При використанні в системі ASLR (рандомізація макета адресного простору) деякі біти L з базовою адресою купи містять випадкові значення, які використовуються як ключ для кодування P (вони витягуються операцією зсуву 12 бітів для 4096-байтових сторінок).
Така маніпуляція знижує ризик захоплення вказівника під час експлуатації, Оскільки покажчик не зберігається у вихідному вигляді, і для його заміни потрібно знати інформацію про розташування купи.
Метод ефективний для захисту від атак, що використовують часткове перевизначення покажчика (низький байт зсув), повний перепис покажчиків (переспрямування на код зловмисника) і змініть позицію списку в незрівнянному напрямку.
Як приклад показано, що використання безпечного зв’язування в malloc заблокує використання вразливості CVE-2020-6007, нещодавно виявленої тими ж дослідниками в розумному підсвічуванні Philips Hue Bridge, спричиненому переповненням буфера і дозволяючи керувати пристроєм .
Фуенте: https://research.checkpoint.com