Контролна точка (глобален доставчик на решения за ИТ сигурност) пусна преди няколко дни въведението на механизма за безопасност "Безопасно свързване", че затруднява създаването на подвизи които манипулират дефиницията или промяната на указатели към разпределени буфери при извършване на повикване на malloc.
Новият механизъм «Безопасно свързване» не блокира напълно възможността за използване на уязвимости, но с минимални режийни разходи усложнява създаването на определени категории експлойтиТъй като в допълнение към експлоатираното препълване на буфер, е необходимо да се намери и друга уязвимост, която причинява информация за местоположението на купчината в паметта.
Пачове за внедряване на Safe-Linking бяха подготвени за Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) и Google TCMalloc, както и предложение за модернизиране на защитата в Chromium (от 2012 г. Chromium вече е интегриран с решения за същият проблем) Техника за защита на MaskPtr, но решението на Checkpoint показва по-добра производителност).
Предложените корекции вече са одобрени за доставка през августската версия на Glibc 3.32 и Safe-Linking ще бъде активирана по подразбиране. В uClibc-NG поддръжката на защитена връзка е включена във версия 1.0.33 и е активирана по подразбиране. В gperftools (стар tcmalloc) промените се приемат, но ще се предлагат като опция в бъдеща версия.
Разработчиците на TCMalloc отказаха да приемат промяната, cсъс силен успех в изпълнението и необходимостта от добавяне на разширени тестове, за да се проверява редовно дали всичко работи правилно.
Тестове, извършени от Инженерите на контролни точки показаха, че методът на безопасно свързване не води до допълнителна консумация на памет а производителността при извършване на операции с купчина средно намалява само с 0.02%, а в най-лошия случай с 1.5%
Активирането на безопасно свързване води до изпълнение на 2-3 допълнителни инструкции на асемблера при всяко обаждане до free () и 3-4 инструкции при извикване на malloc (). Не е необходимо стартиране на инициализация и генериране на произволна стойност.
Safe-Linking може да се използва не само за повишаване на безопасността на различни реализации на купчина, sino също за добавяне на проверки на целостта към всяка структура от данни който използва списък с индивидуално свързани указатели, разположени до буферите.
Методът той е много лесен за изпълнение и изисква само добавяне на макрос и го приложите към указателите към следващия блок на кода (например за Glibc се променят само няколко реда в кода).
Същността на метода е да се прилагат случайни данни от механизма за рандомизация на ASLR адреси (mmap_base) за защита на индивидуално свързани списъци като Fast-Bins и TCache. Преди да приложите стойността на показалеца към следващия елемент в списъка, проверката за преобразуване и подравняване на маска се извършва по ръба на страницата с памет. Показалецът се заменя с резултата от операцията "(L >> PAGE_SHIFT) XOR (P)", където P е стойността на показалеца, а L е местоположението в паметта, където се съхранява този указател.
Когато се използват в системата ASLR (Address Space Layout Randomization), някои от L бита с основния адрес на купчината съдържат произволни стойности, които се използват като ключ за кодиране на P (те се извличат чрез операция за смяна от 12 бита за 4096-байтови страници).
Такава манипулация намалява риска от улавяне на указател в експлойт, Тъй като показалецът не се съхранява в оригиналната си форма и за да го замените, трябва да знаете информация за местоположението на купчината.
Методът е ефективен при защита срещу атаки, които използват частично предефиниране на показалеца (ниско байтно изместване), пълно пренаписване на указатели (пренасочване към кода на нападателя) и промяна на позицията на списъка в необвързана посока.
Като пример е показано, че използването на Safe-Linking в malloc би блокирало експлоатацията на уязвимостта CVE-2020-6007, наскоро открита от същите изследователи в интелигентната подсветка на Philips Hue Bridge, причинена от препълването на буфера и позволяваща контрол устройството.
Fuente: https://research.checkpoint.com