Контрольно-пропускной пункт (глобальный поставщик решений для ИТ-безопасности) выпустил несколько дней назад введение предохранительного механизма "Безопасное связывание", что затрудняет создание эксплойтов которые манипулируют определением или изменением указателей на выделенные буферы при выполнении вызова malloc.
Новый механизм «Safe-Linking» не полностью блокирует возможность эксплуатации уязвимостей, но с минимальными накладными расходами усложняет создание определенных категорий эксплойтовПоскольку помимо эксплуатируемого переполнения буфера, необходимо найти еще одну уязвимость, вызывающую информацию о расположении кучи в памяти.
Были подготовлены патчи реализации 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с высокой производительностью и необходимостью добавлять расширенные тесты, чтобы регулярно проверять, что все работает должным образом.
Испытания, проведенные Инженеры Check Point показали, что метод Safe-Linking не приводит к дополнительному потреблению памяти. а производительность при выполнении операций с кучей в среднем снижается всего на 0.02%, а в худшем случае - на 1.5%
Включение Safe-Linking приводит к выполнению 2-3 дополнительных инструкций ассемблера при каждом вызове free () и 3-4 инструкций при вызове malloc (). Запуск инициализации и генерация случайных значений не требуется.
Safe-Linking можно использовать не только для повышения безопасности различных реализаций кучи, сino также для добавления проверок целостности в любую структуру данных который использует список индивидуально связанных указателей, расположенных рядом с буферами.
Метод это очень просто реализовать и требует только добавления макроса и примените его к указателям на следующий блок кода (например, для Glibc в коде изменены только несколько строк).
Суть метода заключается в применении случайных данных из механизма рандомизации адресов ASLR (mmap_base) для защиты индивидуально связанных списков, таких как Fast-Bins и TCache. Перед применением значения указателя к следующему элементу в списке выполняется преобразование маски и проверка выравнивания по краю страницы памяти. Указатель заменяется результатом операции «(L >> PAGE_SHIFT) XOR (P)», где P - значение указателя, а L - место в памяти, где этот указатель хранится.
При использовании в системе ASLR (рандомизация разметки адресного пространства) некоторые из L битов с базовым адресом кучи содержат случайные значения, которые используются в качестве ключа для кодирования P (они извлекаются 12 битами для 4096-байтового страниц).
Такая манипуляция снижает риск захвата указателя в эксплойте, Поскольку указатель не сохраняется в исходном виде, и для его замены необходимо знать информацию о расположении кучи.
Метод эффективен для защиты от атак, использующих частичное переопределение указателя. (сдвиг младшего байта), полное переписывание указателей (перенаправление на код злоумышленника) и перемещение списка в несогласованном направлении
В качестве примера показано, что использование Safe-Linking в malloc заблокировало бы использование уязвимости CVE-2020-6007, недавно обнаруженной теми же исследователями в интеллектуальной подсветке Philips Hue Bridge, вызванной переполнением буфера и позволяющей управлять устройство.
источник: https://research.checkpoint.com