Safe-Linking - устранение 20-летнего эксплойт примитива функции malloc()
21 мая 2020 г.
Исследователь: Eyal Itkin
Обзор
Одна из наших целей для каждого исследовательского проекта, над которым мы работаем в Check Point Research, это получить глубокое понимание того, как работает программное обеспечение. Какие компоненты оно содержат? Уязвимо ли оно? Как злоумышленники могут использовать эти уязвимости? И что более важно, как мы можем защититься от таких атак?
В нашем последнем исследовании, мы создали механизм безопасности, называемый "Безопасная-Линковка" для защиты односвязных списков в функции malloc() от взлома злоумышленником. Мы успешно применили наш подход к основным библиотекам с открытым исходным кодом, и теперь он интегрирован в наиболее распространенную реализацию стандартной библиотеки glibc (Linux) и ее популярный встроенный аналог, библиотеку uClibc-NG.
Важно отметить, что "Безопасная Линковка" не волшебная пуля, которая остановит все попытки эксплуатации современных реализаций кучи. Однако, это еще один шаг в правильном направлении. Исходя из нашего прошлого опыта, этот конкретный подход мог бы заблокировать несколько крупных эксплоитов, которые мы демонстрировали на протяжении многих лет, превращая, таким образом, "сломанные" программные продукты в "неэксплуатируемые".
Происхождение
С первых дней бинарной эксплуатации, внутренние структуры данных кучи были основной целью для злоумышленников. Понимая, как работают функции кучи malloc() и free(), злоумышленники смогли перевести первичную уязвимость в буфере кучи, такую как линейное переполнение буфера, в более сильный примитив эксплоита, такой как Произвольная-Запись.
Пример этого подробно описан в статье Phrack за 2001 год: Vudo Malloc Tricks (http://phrack.org/issues/57/8.html). В этой статье рассматриваются внутренние возможности реализации нескольких куч и описывается то, что сейчас называется “ Unsafe-Unlinking”. Злоумышленники, которые изменяют указатели FD и BK в двухсвязных списках (например, Small-Bins), могут использовать операцию unlink() для запуска Произвольной-Записи и, таким образом, добиться выполнения кода над целевой программой.
И действительно, glibc версии 2.3.6 от 2005 года включила исправление в этот известный примитив эксплоита под названием “ Safe-Unlinking”. Это элегантное исправление проверяет целостность двухсвязного узла перед тем, как отсоединить его от списка, как видно на рисунке 1:
Рисунок 1: Safe-Unlinking в действии - проверка p->fd->bk == p.
Хотя этот примитив эксплоита был заблокирован более 15 лет назад, в то время никто не придумал аналогичного решения для защиты указателей в односвязных списках. Используя это уязвимое место, злоумышленники переключили свое внимание на эти незащищенные односвязные списки, такие как Fast-Bins, а также TCache (Кэш Потока). Разрушение единственного связанного списка позволяет атакующему получить примитив Arbitrary-Malloc, то есть небольшое контролируемое выделение в произвольном адресе памяти.
В этой статье, мы ликвидируем этот почти 20-летний пробел в безопасности и покажем, как мы создали механизм безопасности для защиты односвязных списков.
Прежде чем мы углубимся в дизайн Безопасного-Связывания, давайте рассмотрим пример эксплуатации, нацеленный на уязвимые Fast-Bins. Читатели, имеющие большой опыт в таких методах эксплуатации, могут свободно переходить к разделу Введение в Safe-Linking.
Экспериментальный пример эксплуатации - CVE-2020-6007:
Во время нашего исследования по взлому интеллектуальных лампочек, мы обнаружили уязвимость переполнения буфера на основе кучи: CVE-2020-6007 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6007). В процессе эксплуатации этой уязвимости высокой степени опасности мы показываем, как злоумышленники используют незащищенные односвязные списки Fast-Bins для преобразования линейного переполнения буфера в гораздо более мощную Произвольную-Запись.
В нашем тестовом примере, куча представляет собой простую реализацию dlmalloc (http://gee.cs.oswego.edu/dl/html/malloc.html) или, более конкретно, реализацию "malloc-standard" uClibc (micro LibC https://www.uclibc.org/), скомпилированной для 32-битной версии. На рисунке 2 показаны метаданные, используемые этой реализацией кучи:
Рисунок 2: структура malloc_chunk , используемая в реализации кучи
Замечания:
- Когда буфер выделен и используется, первые два поля сохраняются перед буфером пользовательских данных.
- Когда буфер освобождается и помещается в Fast-Bin, третье поле также используется и указывает на следующий узел в связанном списке Fast-Bin. Это поле находится в первых 4 байтах пользовательского буфера.
- Когда буфер освобожден и не помещен в Fast-Bin, третье и четвертое поля используются как часть двусвязного списка. Эти поля расположены в первых 8 байтах пользовательского буфера.
Fast-Bins - это массив "ячеек" разных размеров, каждая из которых содержит один связанный список чанков до определенного размера. Минимальный размер ячейки содержит буферы размером до 0x10 байтов. Следующий содержит буферы размером от 0x11 до 0x18 байтов и так далее.
План переполнения
Не вдаваясь в подробности, наша уязвимость дает нам небольшое, но управляемое переполнение буфера на основе кучи. Наш главный план заключается в переполнении смежного свободного буфера, который находится в Fast-Bin. На рисунке 3 показано, как выглядят буферы до нашего переполнения:
Рисунок 3: Наш контролируемый буфер ( синим цветом ) помещен перед освобожденным буфером ( синим цветом ).
На рисунке 4 показаны те же два буфера после нашего переполнения:
Рисунок 4: Наше Переполнение модифицировано поле size и ptr освобожденного буфера (показано красным ).
Используя наше переполнение, мы изменяем то, что, как мы надеемся, является односвязным указателем записи Fast-Bin. Изменяя этот указатель на наш собственный произвольный адрес, мы можем заставить кучу думать, что новый освобожденный чанк теперь хранится там. На рисунке 5 показан поврежденный односвязный список Fast-Bin, как он выглядит в куче:
Рисунок 5: Поврежденный односвязный список Fast-Bin красного цвета .
Запуская последовательность распределений размера, соответствующего размеру соответствующей Fast-Bin, мы получаем примитив Malloc-Where. Остальные технические подробности о создании полного эксплойта для выполнения кода, а также полное исследование лампочек будут опубликованы в следующем посте в блоге.
Примечание: Некоторые из вас могут сказать, что полученный нами примитив Malloc-Where ограничен, так как фиктивный "Свободный Чанк" должен начинаться с поля размера, которое совпадает с полем текущего Fast-Bin. Однако эта дополнительная проверка была реализована только в glibc и отсутствует в uClibc-NG. Поэтому у нас нет никаких ограничений для нашего примитива Malloc-Where.
Представляем Safe-Linking:
После окончания исследования лампочек, у нас было немного свободного времени до начала 36C3(Chaos Communication Congress ), и я планировал решить некоторые проблемы с недавних соревнований CTF. Вместо этого, я снова подумал о недавно разработанном эксплоите. Я почти десять лет эксплуатировал переполнения буфера на основе кучи, всегда ориентируясь на один связанный список в куче. Даже в задачах CTF, я все еще фокусировался на уязвимых односвязных списках Tcache. Конечно, есть некоторый способ защитить этот популярный примитив.
И так возникла концепция Безопасного-Связывания. Safe-Linking использует случайность из Address Space Layout Randomization (ASLR), которая в настоящее время активно используется в большинстве современных операционных систем, чтобы "подписать" указатели списка. В сочетании с проверками целостности выравнивания чанков, этот новый метод защищает указатели от попыток угона.
Наше решение защищает от 3 распространенных атак, регулярно используемых в современных эксплойтах:
- Частичное переопределение указателя: изменение младших байтов указателя (Little Endian).
- Полное переопределение указателя: перехват указателя на выбранное произвольное местоположение.
- Неразмещенные чанки: указание списка по не выровненному адресу.
Моделирование угроз
В нашей модели угроз, злоумышленник имеет следующие возможности:
- Контролируемое линейное переполнение буфера / опустошение через буфер кучи.
- Относительную произвольную запись через кучу буфера.
Важно отметить, что наш злоумышленник не знает, где находится куча, так как базовый адрес кучи рандомизируется вместе с mmap_base посредством ASLR (подробнее об этом в следующем разделе).
Наше решение поднимает полку и блокирует попытки злоумышленника использовать эксплоит. После развертывания, злоумышленники должны иметь дополнительную возможность в виде утечки-кучи/утечки-указателя. Примером сценария для нашей защиты является зависящий от позиции двоичный файл (загружается без ASLR), который имеет переполнение кучи при анализе входящего пользовательского ввода. Это было именно так в примере, который мы показали ранее в исследовании лампочек.
До сих пор, злоумышленник мог эксплуатировать такие цели без утечки кучи и с минимальным контролем над распределением кучи, полагаясь исключительно на фиксированные адреса двоичного файла. Мы можем блокировать такие попытки эксплуатации и использовать ASLR кучи для получения случайности, когда мы перенаправляем распределение кучи на фиксированные адреса в целевых двоичных файлах.
Защита
На машинах Linux куча рандомизируется через вызов mmap_base, которая следует следующей логике:
По умолчанию rndbit равен 8 на 32-битных машинах Linux и 28 на 64-битных машинах.
Мы обозначаем адрес, в котором указатель на один связанный список хранится как L. Теперь определим следующий расчет:
В соответствии с формулой ASLR, показанной выше, сдвиг позиционирует первые случайные биты из адреса памяти прямо на LSBit маски.
Это приводит нас к нашей схеме защиты. Мы обозначаем односвязный указатель списка через P, и вот так выглядит схема:
Таким образом, случайные биты из адреса L помещаются поверх LSB сохраненного защищенного указателя, как можно видеть на рисунке 6:
Рисунок 6: Маскированный указатель P’покрыт случайными битами, как показано красным .
Этот уровень защиты не позволяет злоумышленнику без знания случайных бит ASLR (показано красным) изменить указатель на контролируемое значение.
Однако, если вы обратили внимание, вы можете легко увидеть, что мы находимся в невыгодном положении по сравнению с механизмом Safe-Unlinking. Хотя злоумышленник не может правильно захватить указатель, мы также ограничены, поскольку не можем проверить, произошла ли модификация указателя. Здесь происходит дополнительная проверка.
Все выделенные чанки в куче выровнены с известным фиксированным смещением, которое обычно составляет 8 байтов на 32-битных машинах и 16 на 64-битных машинах. Проверяя, чтобы каждый указатель функцией reveal(), что он был выровнен соответствующим образом, мы добавляем два важных слоя:
- Злоумышленники должны правильно угадать биты выравнивания.
- Злоумышленники не могут указывать фрагменты на невыровненные адреса памяти.
На 64-битных компьютерах, эта статистическая защита приводит к неудачной попытке атаки. 15 из 16 раз. Если мы вернемся к рисунку 6, то увидим, что значение защищенного указателя заканчивается полубайтом 0x3, что означает, что злоумышленник должен использовать значение 0x3 в своем переполнении, иначе он испортит значение и проверку выравнивания не выполниться.
Даже сама по себе, эта проверка выравнивания предотвращает известные примитивы эксплоита, такие как описанный в этой статье, в котором описывается, как направить Fast-Bin на перехват функции malloc(), чтобы немедленно получить выполнение кода.
Примечание: на процессорах Intel glibc по-прежнему использует выравнивание 0x10 байтов как для 32-битных, так и для 64-битных архитектур, в отличие от общего случая, который мы только что описали выше. Это означает, что для glibc мы предоставляем улучшенную защиту на 32 битных компьютерах и можем статистически блокировать 15 из 16 попыток атак.
Пример реализации
На рисунке 7 показан фрагмент исходного патча, который мы отправили в glibc:
Рисунок 7: Пример фрагмента кода из начальной версии нашего патча, отправленного в glibc.
Хотя с тех пор патч был очищен, мы все еще видим, что необходимая модификация кода для защиты TCache в glibc невелика и проста. Что подводит нас к следующему разделу, бенчмаркингу.
Бенчмаркинг
Сравнительный анализ показал, что добавленный код суммирует до 2-3 ассемблерных-инструкций для функции free() и 3-4 ассемблерные-инструкций для функции malloc(). В библиотеке glibc, изменение было незначительным и не поддается измерению даже при суммировании 1 миллиарда(!) вызовов функций malloc()/free() на одном виртуальном ЦП в GCP. Тесты проводились на 64-битной версии библиотеки. Вот результаты после запуска тестового теста glibc malloc-simple для буферов размером 128 (0x80) байтов на том же сервере GCP:
Рисунок 8: Результаты бенчмаркинга для malloc-simpleтеста glibc .
Более быстрые результаты для каждого теста выделены жирным шрифтом. Как мы видим, результаты практически одинаковы, и в половине тестов исправленная версия была быстрее, что на самом деле не имеет смысла. Обычно это означает, что уровень шума на сервере намного выше, чем фактическое влияние добавленной функции на общие результаты. Короче говоря, это означает, что дополнительные издержки нашей новой функции незначительны, и это хорошая новость.
В качестве другого примера, худшее влияние на бенчмаркинг-тесты функции tcmalloc (gperftools) было связано с накладными расходами в 1,5%, тогда как среднее значение составило всего 0,02%.
Эти результаты сравнительного анализа обусловлены тонкой конструкцией предлагаемого механизма:
- Защита не имеет дополнительной памяти.
- Защита не требует инициализации.
- Никакого специального источника случайности не требуется.
- Защита использует только L и P, которые оба присутствуют в то время, когда указатель должен быть protect() или reveal().
Важно отметить, и что это подробно изложено в документации glibc, что и Fast-Bins, и TCache используют односвязные списки для хранения данных. Они поддерживают только функции put/get, и никакая общая функциональность не пересекает весь список и сохраняет его без изменений. Хотя такая функциональность существует, она используется только для сбора статистики функции malloc (mallinfo), поэтому дополнительные издержки для доступа к односвязному указателю незначительны.
Пересматривая нашу модель угрозы
Проверка выравнивания уменьшает поверхность атаки и требует, чтобы блок Fast-Bin или TCache указывал на выровненный адрес памяти. Это напрямую блокирует известные варианты эксплоитов, как упоминалось выше.
Как и в случае Safe-Unlinking (для двойных списков), наша защита основана на том факте, что злоумышленник не знает, как выглядят законные указатели кучи. В сценарии с двойным списком, злоумышленник, который может подделать структуру памяти и знает, как выглядит действительный указатель кучи, может успешно подделать действительную пару указателей FD/BK, которая не вызовет примитив Произвольной-Записи, но разрешает чанк по адресу, контролируемому злоумышленником.
В сценарии с одно-связанным списком злоумышленник без утечки указателя не сможет полностью контролировать переопределенный указатель из-за уровня защиты, который зависит от случайности, унаследованной от развернутого ASLR. Предлагаемый PAGE_SHIFT размещает случайные биты прямо над первым битом сохраненного указателя. Вместе с проверкой выравнивания, это статистически блокирует злоумышленников от изменения даже самого младшего бита/байта (Little Endian) сохраненного односвязного указателя.
Разворот сюжета - функция MaskPtr()
Нашей целью было объединить Safe-Linking с ведущими открытыми источниками, которые реализуют каждый вид кучи, содержащей односвязнные списки. Одной из таких реализаций является функция tcmalloc (Thread-Cache Malloc) от Google, которая в то время была только с открытым исходным кодом как часть репозитория gperftools. Перед отправкой нашего патча в gperftools (https://github.com/gperftools/gperftools), мы решили взглянуть на Git-репозиторий Chromium, на случай, если они могут использовать другую версию tcmalloc. Что, как выясняется, они и сделали.
Мы пропустим урок истории и сразу перейдем к результатам:
- gperftools появился в 2007 году, и последняя версия - 2.7.90.
- Tcmalloc выглядит так, как будто он основан на версии 2.0 gperftool.
- В феврале 2020 года, после того как мы уже представили исправления во все открытые источники, Google выпустила официальный репозиторий TCMalloc GitHub, который отличается от обеих предыдущих реализаций.
Исследуя версию Chromium, мы увидели, что не только их TCache теперь основан на двойных списках (теперь называемых FL, для Free List), а не на односвязных списках (первоначально назывался SLL), они также добавили особую функцию под нахванием MaskPtr(). При более внимательном рассмотрении виден следующий фрагмент кода:
Код удивительно похож на нашу реализацию PROTECT_PTR. Кроме того, авторы этого патча специально отметили, что "Цель здесь состоит в том, чтобы не допустить распыления в списках freelist".
Похоже, что команда безопасности Chromium представила свою собственную версию Безопасного-Связывания для функции tcmalloc, и они сделали это 8 лет назад, что весьма впечатляет.
Из изучения их кода, мы можем видеть, что их маска основана на (случайном значении) указателя из раздела кода (TCMalloc_SystemAlloc), а не на расположении кучи, как используется в нашей реализации. Кроме того, они сдвигают адрес на жестко закодированное значение 13, а также инвертируют биты своей маски. Поскольку нам не удалось найти документацию, мы можем прочитать из кода, что инверсия битов используется, чтобы гарантировать, что результатом будет неправильный адрес.
Прочитав их логи, мы также узнали, что они оценили снижение производительности этой функции как менее 2%.
По сравнению с нашим проектом, реализация Chromium подразумевает дополнительную ссылку на память (на функцию кода) и дополнительную ассемблерную инструкцию для переключения битов. Их маскирование указателя используется без дополнительной проверки выравнивания, и поэтому код не может заранее отследить изменение указателя без сбоя процесса.
Интеграция
Мы внедрили и протестировали патчи для успешной интеграции предложенного средства защиты с последними версиями glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) и более поздних версий, совершенно нового TCMalloc от Google. Кроме того, мы также указали команде разработчиков Chromium на нашу версию Безопасного-Связывания, которая была представлена gperftools, в надежде, что некоторые из наших улучшений производительности, специфичных для gperftools, найдут свой путь в версии Chromium.
Когда мы начали работать над Безопасным-Связыванием, мы полагали, что интеграция Безопасного-Связывания с этими 3 (теперь 4) доминирующими библиотеками приведет к более широкому принятию другими библиотеками, как в сообществе открытого исходного кода, так и в программном обеспечении с закрытым исходным кодом в отрасли. Тот факт, что базовая версия Безопасным-Связыванием уже встроена в Chromium с 2012 года, подтверждает зрелость этого решения.
Вот результаты интеграции, так как они на момент написания этой записи в блоге.
glibc (ptmalloc)
Статус: Интегрирован. Будет выпущен в версии 2.32 в августе 2020 года.
Активация: по умолчанию включена.
Сопровождающие проекта GNU glibc были очень кооперативными и отзывчивыми. Главным препятствием было подписание юридических документов, которые позволят нам, как сотрудникам корпорации, пожертвовать исходный код, лицензированный по лицензии GPL, в репозиторий GNU. Как только мы преодолели эту проблему, процесс стал действительно плавным, и последняя версия нашего патча была передана в библиотеку и готова к включению в следующую версию.
Мы хотели бы поблагодарить разработчиков glibc за сотрудничество на протяжении всего этого процесса. Их готовность включить в свой проект функцию безопасности “по умолчанию“ была очень приятной, особенно по сравнению с нашими первоначальными ожиданиями и ответом, который мы получили из других репозиториев.
uClibc-NG (dlmalloc)
Статус: Релиз в версии v1.0.33.
Активация: по умолчанию включена.
Отправка нашей функции в uClibc-NG была очень простой, и она была сразу же включена в этот коммит. Мы можем с гордостью сказать, что Safe-Linking уже выпущено как часть версии uClibc-NG v1.0.33. Если мы вернемся к нашему исследованию интеллектуальных лампочек, эта функция заблокировала бы наш эксплойт и вынудила бы нас найти дополнительную уязвимость в продукте.
Еще раз, мы хотим поблагодарить сопровождающих uClibc-NG за сотрудничество в этом процессе.
gperftools (tcmalloc)
Статус: Проходит интеграцию.
Activation: Выключена по умолчанию
Хотя мы ранее упоминали о MaskPtr() функциональности Chromium , доступной с 2012 года, эта функция не нашла доступа ни к одной из общедоступных версий tcmalloc. Итак, мы попытались везти в безопасных ссылках реализацию gcfftools tcmalloc.
Из-за сложного состояния репозитория gperftools, теперь, когда официальный репозиторий Google TCMalloc является публичным, этот процесс продвигался медленно, но медленно. В этом запросе от начала января 2020 года вы видите наши усилия по интеграции этой функции в репозиторий. Первоначальный ответ был тот, который мы боялись: наша функция «разрушает производительность». Напомним, что при использовании набора тестов для репозитория наихудший результат составил 1,5%, а среднее значение составило всего 0,02%.
В конце концов, с некоторым нежеланием мы решили добавить эту функцию как «отключенную по умолчанию», надеясь, что когда-нибудь кто-нибудь активирует эту функцию самостоятельно. Эта функция еще не была объединена, но мы надеемся, что это произойдет в ближайшем будущем.
Мы все еще хотели бы поблагодарить единственного сопровождающего этого проекта, который предложил выполнить все необходимые сантехнические работы, чтобы предоставить пользователям возможность конфигурации для включения Safe-Linking.
TCMalloc (tcmalloc)
Status: Отклонено.
Activation: Информации нет.
Мы отправили наш патч в TCMalloc в этом запросе на получение , который, к сожалению, был сразу отклонен. Мы снова услышали: «Затраты на производительность этого слишком велики, чтобы объединить их», и что они не собираются интегрировать его даже в настраиваемую функцию «по умолчанию отключено»: «Хотя макрос защищен, он добавляет еще одну конфигурацию, которая должен быть построен и регулярно проверяться, чтобы все работало ». Мы не смогли найти представителя Google, который помог бы нам разрешить этот конфликт с владельцами репозитория, и мы оставили его как есть.
К сожалению, похоже, что наиболее распространенная реализация Google malloc(), которая используется в большинстве их проектов на C / C ++ (как упомянуто в документации TCMalloc), не собиралась интегрировать функцию безопасности, которая затруднит использование уязвимостей в их проектах. ,
Заключение
Safe-Linking - это не волшебная пуля, которая остановит все попытки эксплуатации современных реализаций кучи. Однако это еще один шаг в правильном направлении. Вынуждая злоумышленника иметь уязвимость утечки указателя еще до того, как он сможет даже начать использовать эксплоит на основе кучи, мы постепенно поднимаем планку борьбы с эксплуатацией.
Исходя из нашего прошлого опыта, это конкретная защита могла бы заблокировать несколько крупных эксплойтов, которые мы реализовывали на протяжении многих лет, превращая, таким образом, "сломанные" программные продукты в «неэкплуатируемые» (по крайней мере, с учетом уязвимостей, которые были у нас во время соответствующих исследовательских проектов).
Также важно отметить, что наше решение не ограничивается только реализациями кучи. Оно также позволяет находящимся под угрозой структурам данных с помощью односвязных указателей списков, расположенных рядом с пользовательскими буферами, получать защиту целостности без каких-либо дополнительных затрат памяти и с незначительным влиянием времени выполнения. Это решение легко распространяется на каждый список в системе с ASLR.
Это был трудный путь, начиная с того момента, когда мы впервые решили эту проблему в конце 2019 года, и до разработки мер по увеличению безопасности и, наконец, интеграции его в качестве функции безопасности, которая доступна по умолчанию в двух самых известных реализациях libc в мире: glibc и uClibc-NG. В итоге мы получили гораздо лучшие результаты в интеграции этой функции, чем мы изначально ожидали, и поэтому мы хотели бы еще раз поблагодарить всех сопровождающих и исследователей, которые помогли воплотить эту идею в реальность. Постепенно, шаг за шагом, мы поднимаем планку борьбы с эксплуатации и помогаем защитить пользователей во всем мире.
Источник: https://research.checkpoint.com/202...ating-a-20-year-old-malloc-exploit-primitive/
Автор перевода: yashechka
Переведено специально для портала xss.pro (c)
21 мая 2020 г.
Исследователь: Eyal Itkin
Обзор
Одна из наших целей для каждого исследовательского проекта, над которым мы работаем в Check Point Research, это получить глубокое понимание того, как работает программное обеспечение. Какие компоненты оно содержат? Уязвимо ли оно? Как злоумышленники могут использовать эти уязвимости? И что более важно, как мы можем защититься от таких атак?
В нашем последнем исследовании, мы создали механизм безопасности, называемый "Безопасная-Линковка" для защиты односвязных списков в функции malloc() от взлома злоумышленником. Мы успешно применили наш подход к основным библиотекам с открытым исходным кодом, и теперь он интегрирован в наиболее распространенную реализацию стандартной библиотеки glibc (Linux) и ее популярный встроенный аналог, библиотеку uClibc-NG.
Важно отметить, что "Безопасная Линковка" не волшебная пуля, которая остановит все попытки эксплуатации современных реализаций кучи. Однако, это еще один шаг в правильном направлении. Исходя из нашего прошлого опыта, этот конкретный подход мог бы заблокировать несколько крупных эксплоитов, которые мы демонстрировали на протяжении многих лет, превращая, таким образом, "сломанные" программные продукты в "неэксплуатируемые".
Происхождение
С первых дней бинарной эксплуатации, внутренние структуры данных кучи были основной целью для злоумышленников. Понимая, как работают функции кучи malloc() и free(), злоумышленники смогли перевести первичную уязвимость в буфере кучи, такую как линейное переполнение буфера, в более сильный примитив эксплоита, такой как Произвольная-Запись.
Пример этого подробно описан в статье Phrack за 2001 год: Vudo Malloc Tricks (http://phrack.org/issues/57/8.html). В этой статье рассматриваются внутренние возможности реализации нескольких куч и описывается то, что сейчас называется “ Unsafe-Unlinking”. Злоумышленники, которые изменяют указатели FD и BK в двухсвязных списках (например, Small-Bins), могут использовать операцию unlink() для запуска Произвольной-Записи и, таким образом, добиться выполнения кода над целевой программой.
И действительно, glibc версии 2.3.6 от 2005 года включила исправление в этот известный примитив эксплоита под названием “ Safe-Unlinking”. Это элегантное исправление проверяет целостность двухсвязного узла перед тем, как отсоединить его от списка, как видно на рисунке 1:
Рисунок 1: Safe-Unlinking в действии - проверка p->fd->bk == p.
Хотя этот примитив эксплоита был заблокирован более 15 лет назад, в то время никто не придумал аналогичного решения для защиты указателей в односвязных списках. Используя это уязвимое место, злоумышленники переключили свое внимание на эти незащищенные односвязные списки, такие как Fast-Bins, а также TCache (Кэш Потока). Разрушение единственного связанного списка позволяет атакующему получить примитив Arbitrary-Malloc, то есть небольшое контролируемое выделение в произвольном адресе памяти.
В этой статье, мы ликвидируем этот почти 20-летний пробел в безопасности и покажем, как мы создали механизм безопасности для защиты односвязных списков.
Прежде чем мы углубимся в дизайн Безопасного-Связывания, давайте рассмотрим пример эксплуатации, нацеленный на уязвимые Fast-Bins. Читатели, имеющие большой опыт в таких методах эксплуатации, могут свободно переходить к разделу Введение в Safe-Linking.
Экспериментальный пример эксплуатации - CVE-2020-6007:
Во время нашего исследования по взлому интеллектуальных лампочек, мы обнаружили уязвимость переполнения буфера на основе кучи: CVE-2020-6007 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6007). В процессе эксплуатации этой уязвимости высокой степени опасности мы показываем, как злоумышленники используют незащищенные односвязные списки Fast-Bins для преобразования линейного переполнения буфера в гораздо более мощную Произвольную-Запись.
В нашем тестовом примере, куча представляет собой простую реализацию dlmalloc (http://gee.cs.oswego.edu/dl/html/malloc.html) или, более конкретно, реализацию "malloc-standard" uClibc (micro LibC https://www.uclibc.org/), скомпилированной для 32-битной версии. На рисунке 2 показаны метаданные, используемые этой реализацией кучи:
Рисунок 2: структура malloc_chunk , используемая в реализации кучи
Замечания:
- Когда буфер выделен и используется, первые два поля сохраняются перед буфером пользовательских данных.
- Когда буфер освобождается и помещается в Fast-Bin, третье поле также используется и указывает на следующий узел в связанном списке Fast-Bin. Это поле находится в первых 4 байтах пользовательского буфера.
- Когда буфер освобожден и не помещен в Fast-Bin, третье и четвертое поля используются как часть двусвязного списка. Эти поля расположены в первых 8 байтах пользовательского буфера.
Fast-Bins - это массив "ячеек" разных размеров, каждая из которых содержит один связанный список чанков до определенного размера. Минимальный размер ячейки содержит буферы размером до 0x10 байтов. Следующий содержит буферы размером от 0x11 до 0x18 байтов и так далее.
План переполнения
Не вдаваясь в подробности, наша уязвимость дает нам небольшое, но управляемое переполнение буфера на основе кучи. Наш главный план заключается в переполнении смежного свободного буфера, который находится в Fast-Bin. На рисунке 3 показано, как выглядят буферы до нашего переполнения:
Рисунок 3: Наш контролируемый буфер ( синим цветом ) помещен перед освобожденным буфером ( синим цветом ).
На рисунке 4 показаны те же два буфера после нашего переполнения:
Рисунок 4: Наше Переполнение модифицировано поле size и ptr освобожденного буфера (показано красным ).
Используя наше переполнение, мы изменяем то, что, как мы надеемся, является односвязным указателем записи Fast-Bin. Изменяя этот указатель на наш собственный произвольный адрес, мы можем заставить кучу думать, что новый освобожденный чанк теперь хранится там. На рисунке 5 показан поврежденный односвязный список Fast-Bin, как он выглядит в куче:
Рисунок 5: Поврежденный односвязный список Fast-Bin красного цвета .
Запуская последовательность распределений размера, соответствующего размеру соответствующей Fast-Bin, мы получаем примитив Malloc-Where. Остальные технические подробности о создании полного эксплойта для выполнения кода, а также полное исследование лампочек будут опубликованы в следующем посте в блоге.
Примечание: Некоторые из вас могут сказать, что полученный нами примитив Malloc-Where ограничен, так как фиктивный "Свободный Чанк" должен начинаться с поля размера, которое совпадает с полем текущего Fast-Bin. Однако эта дополнительная проверка была реализована только в glibc и отсутствует в uClibc-NG. Поэтому у нас нет никаких ограничений для нашего примитива Malloc-Where.
Представляем Safe-Linking:
После окончания исследования лампочек, у нас было немного свободного времени до начала 36C3(Chaos Communication Congress ), и я планировал решить некоторые проблемы с недавних соревнований CTF. Вместо этого, я снова подумал о недавно разработанном эксплоите. Я почти десять лет эксплуатировал переполнения буфера на основе кучи, всегда ориентируясь на один связанный список в куче. Даже в задачах CTF, я все еще фокусировался на уязвимых односвязных списках Tcache. Конечно, есть некоторый способ защитить этот популярный примитив.
И так возникла концепция Безопасного-Связывания. Safe-Linking использует случайность из Address Space Layout Randomization (ASLR), которая в настоящее время активно используется в большинстве современных операционных систем, чтобы "подписать" указатели списка. В сочетании с проверками целостности выравнивания чанков, этот новый метод защищает указатели от попыток угона.
Наше решение защищает от 3 распространенных атак, регулярно используемых в современных эксплойтах:
- Частичное переопределение указателя: изменение младших байтов указателя (Little Endian).
- Полное переопределение указателя: перехват указателя на выбранное произвольное местоположение.
- Неразмещенные чанки: указание списка по не выровненному адресу.
Моделирование угроз
В нашей модели угроз, злоумышленник имеет следующие возможности:
- Контролируемое линейное переполнение буфера / опустошение через буфер кучи.
- Относительную произвольную запись через кучу буфера.
Важно отметить, что наш злоумышленник не знает, где находится куча, так как базовый адрес кучи рандомизируется вместе с mmap_base посредством ASLR (подробнее об этом в следующем разделе).
Наше решение поднимает полку и блокирует попытки злоумышленника использовать эксплоит. После развертывания, злоумышленники должны иметь дополнительную возможность в виде утечки-кучи/утечки-указателя. Примером сценария для нашей защиты является зависящий от позиции двоичный файл (загружается без ASLR), который имеет переполнение кучи при анализе входящего пользовательского ввода. Это было именно так в примере, который мы показали ранее в исследовании лампочек.
До сих пор, злоумышленник мог эксплуатировать такие цели без утечки кучи и с минимальным контролем над распределением кучи, полагаясь исключительно на фиксированные адреса двоичного файла. Мы можем блокировать такие попытки эксплуатации и использовать ASLR кучи для получения случайности, когда мы перенаправляем распределение кучи на фиксированные адреса в целевых двоичных файлах.
Защита
На машинах Linux куча рандомизируется через вызов mmap_base, которая следует следующей логике:
random_base = ((1 << rndbits) - 1) << PAGE_SHIFT) По умолчанию rndbit равен 8 на 32-битных машинах Linux и 28 на 64-битных машинах.
Мы обозначаем адрес, в котором указатель на один связанный список хранится как L. Теперь определим следующий расчет:
Mask := (L >> PAGE_SHIFT) В соответствии с формулой ASLR, показанной выше, сдвиг позиционирует первые случайные биты из адреса памяти прямо на LSBit маски.
Это приводит нас к нашей схеме защиты. Мы обозначаем односвязный указатель списка через P, и вот так выглядит схема:
- PROTECT(P) := (L >> PAGE_SHIFT) XOR (P)
- *L = PROTECT(P)
C:
#define PROTECT_PTR(pos, ptr, type) \
((type)((((size_t)pos) >> PAGE_SHIFT) ^ ((size_t)ptr)))
#define REVEAL_PTR(pos, ptr, type) \
PROTECT_PTR(pos, ptr, type)Таким образом, случайные биты из адреса L помещаются поверх LSB сохраненного защищенного указателя, как можно видеть на рисунке 6:
Рисунок 6: Маскированный указатель P’покрыт случайными битами, как показано красным .
Этот уровень защиты не позволяет злоумышленнику без знания случайных бит ASLR (показано красным) изменить указатель на контролируемое значение.
Однако, если вы обратили внимание, вы можете легко увидеть, что мы находимся в невыгодном положении по сравнению с механизмом Safe-Unlinking. Хотя злоумышленник не может правильно захватить указатель, мы также ограничены, поскольку не можем проверить, произошла ли модификация указателя. Здесь происходит дополнительная проверка.
Все выделенные чанки в куче выровнены с известным фиксированным смещением, которое обычно составляет 8 байтов на 32-битных машинах и 16 на 64-битных машинах. Проверяя, чтобы каждый указатель функцией reveal(), что он был выровнен соответствующим образом, мы добавляем два важных слоя:
- Злоумышленники должны правильно угадать биты выравнивания.
- Злоумышленники не могут указывать фрагменты на невыровненные адреса памяти.
На 64-битных компьютерах, эта статистическая защита приводит к неудачной попытке атаки. 15 из 16 раз. Если мы вернемся к рисунку 6, то увидим, что значение защищенного указателя заканчивается полубайтом 0x3, что означает, что злоумышленник должен использовать значение 0x3 в своем переполнении, иначе он испортит значение и проверку выравнивания не выполниться.
Даже сама по себе, эта проверка выравнивания предотвращает известные примитивы эксплоита, такие как описанный в этой статье, в котором описывается, как направить Fast-Bin на перехват функции malloc(), чтобы немедленно получить выполнение кода.
Примечание: на процессорах Intel glibc по-прежнему использует выравнивание 0x10 байтов как для 32-битных, так и для 64-битных архитектур, в отличие от общего случая, который мы только что описали выше. Это означает, что для glibc мы предоставляем улучшенную защиту на 32 битных компьютерах и можем статистически блокировать 15 из 16 попыток атак.
Пример реализации
На рисунке 7 показан фрагмент исходного патча, который мы отправили в glibc:
Рисунок 7: Пример фрагмента кода из начальной версии нашего патча, отправленного в glibc.
Хотя с тех пор патч был очищен, мы все еще видим, что необходимая модификация кода для защиты TCache в glibc невелика и проста. Что подводит нас к следующему разделу, бенчмаркингу.
Бенчмаркинг
Сравнительный анализ показал, что добавленный код суммирует до 2-3 ассемблерных-инструкций для функции free() и 3-4 ассемблерные-инструкций для функции malloc(). В библиотеке glibc, изменение было незначительным и не поддается измерению даже при суммировании 1 миллиарда(!) вызовов функций malloc()/free() на одном виртуальном ЦП в GCP. Тесты проводились на 64-битной версии библиотеки. Вот результаты после запуска тестового теста glibc malloc-simple для буферов размером 128 (0x80) байтов на том же сервере GCP:
Рисунок 8: Результаты бенчмаркинга для malloc-simpleтеста glibc .
Более быстрые результаты для каждого теста выделены жирным шрифтом. Как мы видим, результаты практически одинаковы, и в половине тестов исправленная версия была быстрее, что на самом деле не имеет смысла. Обычно это означает, что уровень шума на сервере намного выше, чем фактическое влияние добавленной функции на общие результаты. Короче говоря, это означает, что дополнительные издержки нашей новой функции незначительны, и это хорошая новость.
В качестве другого примера, худшее влияние на бенчмаркинг-тесты функции tcmalloc (gperftools) было связано с накладными расходами в 1,5%, тогда как среднее значение составило всего 0,02%.
Эти результаты сравнительного анализа обусловлены тонкой конструкцией предлагаемого механизма:
- Защита не имеет дополнительной памяти.
- Защита не требует инициализации.
- Никакого специального источника случайности не требуется.
- Защита использует только L и P, которые оба присутствуют в то время, когда указатель должен быть protect() или reveal().
Важно отметить, и что это подробно изложено в документации glibc, что и Fast-Bins, и TCache используют односвязные списки для хранения данных. Они поддерживают только функции put/get, и никакая общая функциональность не пересекает весь список и сохраняет его без изменений. Хотя такая функциональность существует, она используется только для сбора статистики функции malloc (mallinfo), поэтому дополнительные издержки для доступа к односвязному указателю незначительны.
Пересматривая нашу модель угрозы
Проверка выравнивания уменьшает поверхность атаки и требует, чтобы блок Fast-Bin или TCache указывал на выровненный адрес памяти. Это напрямую блокирует известные варианты эксплоитов, как упоминалось выше.
Как и в случае Safe-Unlinking (для двойных списков), наша защита основана на том факте, что злоумышленник не знает, как выглядят законные указатели кучи. В сценарии с двойным списком, злоумышленник, который может подделать структуру памяти и знает, как выглядит действительный указатель кучи, может успешно подделать действительную пару указателей FD/BK, которая не вызовет примитив Произвольной-Записи, но разрешает чанк по адресу, контролируемому злоумышленником.
В сценарии с одно-связанным списком злоумышленник без утечки указателя не сможет полностью контролировать переопределенный указатель из-за уровня защиты, который зависит от случайности, унаследованной от развернутого ASLR. Предлагаемый PAGE_SHIFT размещает случайные биты прямо над первым битом сохраненного указателя. Вместе с проверкой выравнивания, это статистически блокирует злоумышленников от изменения даже самого младшего бита/байта (Little Endian) сохраненного односвязного указателя.
Разворот сюжета - функция MaskPtr()
Нашей целью было объединить Safe-Linking с ведущими открытыми источниками, которые реализуют каждый вид кучи, содержащей односвязнные списки. Одной из таких реализаций является функция tcmalloc (Thread-Cache Malloc) от Google, которая в то время была только с открытым исходным кодом как часть репозитория gperftools. Перед отправкой нашего патча в gperftools (https://github.com/gperftools/gperftools), мы решили взглянуть на Git-репозиторий Chromium, на случай, если они могут использовать другую версию tcmalloc. Что, как выясняется, они и сделали.
Мы пропустим урок истории и сразу перейдем к результатам:
- gperftools появился в 2007 году, и последняя версия - 2.7.90.
- Tcmalloc выглядит так, как будто он основан на версии 2.0 gperftool.
- В феврале 2020 года, после того как мы уже представили исправления во все открытые источники, Google выпустила официальный репозиторий TCMalloc GitHub, который отличается от обеих предыдущих реализаций.
Исследуя версию Chromium, мы увидели, что не только их TCache теперь основан на двойных списках (теперь называемых FL, для Free List), а не на односвязных списках (первоначально назывался SLL), они также добавили особую функцию под нахванием MaskPtr(). При более внимательном рассмотрении виден следующий фрагмент кода:
C:
inline void* MaskPtr(void* p) {
// Maximize ASLR entropy and guarantee the result is an invalid address.
const uintptr_t mask =
~(reinterpret_cast<uintptr_t>(TCMalloc_SystemAlloc) >> 13);
return reinterpret_cast<void*>(reinterpret_cast<uintptr_t>(p) ^ mask);
}Код удивительно похож на нашу реализацию PROTECT_PTR. Кроме того, авторы этого патча специально отметили, что "Цель здесь состоит в том, чтобы не допустить распыления в списках freelist".
Похоже, что команда безопасности Chromium представила свою собственную версию Безопасного-Связывания для функции tcmalloc, и они сделали это 8 лет назад, что весьма впечатляет.
Из изучения их кода, мы можем видеть, что их маска основана на (случайном значении) указателя из раздела кода (TCMalloc_SystemAlloc), а не на расположении кучи, как используется в нашей реализации. Кроме того, они сдвигают адрес на жестко закодированное значение 13, а также инвертируют биты своей маски. Поскольку нам не удалось найти документацию, мы можем прочитать из кода, что инверсия битов используется, чтобы гарантировать, что результатом будет неправильный адрес.
Прочитав их логи, мы также узнали, что они оценили снижение производительности этой функции как менее 2%.
По сравнению с нашим проектом, реализация Chromium подразумевает дополнительную ссылку на память (на функцию кода) и дополнительную ассемблерную инструкцию для переключения битов. Их маскирование указателя используется без дополнительной проверки выравнивания, и поэтому код не может заранее отследить изменение указателя без сбоя процесса.
Интеграция
Мы внедрили и протестировали патчи для успешной интеграции предложенного средства защиты с последними версиями glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) и более поздних версий, совершенно нового TCMalloc от Google. Кроме того, мы также указали команде разработчиков Chromium на нашу версию Безопасного-Связывания, которая была представлена gperftools, в надежде, что некоторые из наших улучшений производительности, специфичных для gperftools, найдут свой путь в версии Chromium.
Когда мы начали работать над Безопасным-Связыванием, мы полагали, что интеграция Безопасного-Связывания с этими 3 (теперь 4) доминирующими библиотеками приведет к более широкому принятию другими библиотеками, как в сообществе открытого исходного кода, так и в программном обеспечении с закрытым исходным кодом в отрасли. Тот факт, что базовая версия Безопасным-Связыванием уже встроена в Chromium с 2012 года, подтверждает зрелость этого решения.
Вот результаты интеграции, так как они на момент написания этой записи в блоге.
glibc (ptmalloc)
Статус: Интегрирован. Будет выпущен в версии 2.32 в августе 2020 года.
Активация: по умолчанию включена.
Сопровождающие проекта GNU glibc были очень кооперативными и отзывчивыми. Главным препятствием было подписание юридических документов, которые позволят нам, как сотрудникам корпорации, пожертвовать исходный код, лицензированный по лицензии GPL, в репозиторий GNU. Как только мы преодолели эту проблему, процесс стал действительно плавным, и последняя версия нашего патча была передана в библиотеку и готова к включению в следующую версию.
Мы хотели бы поблагодарить разработчиков glibc за сотрудничество на протяжении всего этого процесса. Их готовность включить в свой проект функцию безопасности “по умолчанию“ была очень приятной, особенно по сравнению с нашими первоначальными ожиданиями и ответом, который мы получили из других репозиториев.
uClibc-NG (dlmalloc)
Статус: Релиз в версии v1.0.33.
Активация: по умолчанию включена.
Отправка нашей функции в uClibc-NG была очень простой, и она была сразу же включена в этот коммит. Мы можем с гордостью сказать, что Safe-Linking уже выпущено как часть версии uClibc-NG v1.0.33. Если мы вернемся к нашему исследованию интеллектуальных лампочек, эта функция заблокировала бы наш эксплойт и вынудила бы нас найти дополнительную уязвимость в продукте.
Еще раз, мы хотим поблагодарить сопровождающих uClibc-NG за сотрудничество в этом процессе.
gperftools (tcmalloc)
Статус: Проходит интеграцию.
Activation: Выключена по умолчанию
Хотя мы ранее упоминали о MaskPtr() функциональности Chromium , доступной с 2012 года, эта функция не нашла доступа ни к одной из общедоступных версий tcmalloc. Итак, мы попытались везти в безопасных ссылках реализацию gcfftools tcmalloc.
Из-за сложного состояния репозитория gperftools, теперь, когда официальный репозиторий Google TCMalloc является публичным, этот процесс продвигался медленно, но медленно. В этом запросе от начала января 2020 года вы видите наши усилия по интеграции этой функции в репозиторий. Первоначальный ответ был тот, который мы боялись: наша функция «разрушает производительность». Напомним, что при использовании набора тестов для репозитория наихудший результат составил 1,5%, а среднее значение составило всего 0,02%.
В конце концов, с некоторым нежеланием мы решили добавить эту функцию как «отключенную по умолчанию», надеясь, что когда-нибудь кто-нибудь активирует эту функцию самостоятельно. Эта функция еще не была объединена, но мы надеемся, что это произойдет в ближайшем будущем.
Мы все еще хотели бы поблагодарить единственного сопровождающего этого проекта, который предложил выполнить все необходимые сантехнические работы, чтобы предоставить пользователям возможность конфигурации для включения Safe-Linking.
TCMalloc (tcmalloc)
Status: Отклонено.
Activation: Информации нет.
Мы отправили наш патч в TCMalloc в этом запросе на получение , который, к сожалению, был сразу отклонен. Мы снова услышали: «Затраты на производительность этого слишком велики, чтобы объединить их», и что они не собираются интегрировать его даже в настраиваемую функцию «по умолчанию отключено»: «Хотя макрос защищен, он добавляет еще одну конфигурацию, которая должен быть построен и регулярно проверяться, чтобы все работало ». Мы не смогли найти представителя Google, который помог бы нам разрешить этот конфликт с владельцами репозитория, и мы оставили его как есть.
К сожалению, похоже, что наиболее распространенная реализация Google malloc(), которая используется в большинстве их проектов на C / C ++ (как упомянуто в документации TCMalloc), не собиралась интегрировать функцию безопасности, которая затруднит использование уязвимостей в их проектах. ,
Заключение
Safe-Linking - это не волшебная пуля, которая остановит все попытки эксплуатации современных реализаций кучи. Однако это еще один шаг в правильном направлении. Вынуждая злоумышленника иметь уязвимость утечки указателя еще до того, как он сможет даже начать использовать эксплоит на основе кучи, мы постепенно поднимаем планку борьбы с эксплуатацией.
Исходя из нашего прошлого опыта, это конкретная защита могла бы заблокировать несколько крупных эксплойтов, которые мы реализовывали на протяжении многих лет, превращая, таким образом, "сломанные" программные продукты в «неэкплуатируемые» (по крайней мере, с учетом уязвимостей, которые были у нас во время соответствующих исследовательских проектов).
Также важно отметить, что наше решение не ограничивается только реализациями кучи. Оно также позволяет находящимся под угрозой структурам данных с помощью односвязных указателей списков, расположенных рядом с пользовательскими буферами, получать защиту целостности без каких-либо дополнительных затрат памяти и с незначительным влиянием времени выполнения. Это решение легко распространяется на каждый список в системе с ASLR.
Это был трудный путь, начиная с того момента, когда мы впервые решили эту проблему в конце 2019 года, и до разработки мер по увеличению безопасности и, наконец, интеграции его в качестве функции безопасности, которая доступна по умолчанию в двух самых известных реализациях libc в мире: glibc и uClibc-NG. В итоге мы получили гораздо лучшие результаты в интеграции этой функции, чем мы изначально ожидали, и поэтому мы хотели бы еще раз поблагодарить всех сопровождающих и исследователей, которые помогли воплотить эту идею в реальность. Постепенно, шаг за шагом, мы поднимаем планку борьбы с эксплуатации и помогаем защитить пользователей во всем мире.
Источник: https://research.checkpoint.com/202...ating-a-20-year-old-malloc-exploit-primitive/
Автор перевода: yashechka
Переведено специально для портала xss.pro (c)