Вопрос или проблема
Я исследую уязвимости безопасности памяти и заметил, что в приложениях, не являющихся браузерами (например, в ядре Linux), записи деталей CVE для уязвимостей “использование после освобождения” почти всегда классифицируются как ошибки отказа в обслуживании, а не как ошибки удаленного выполнения кода. Они даже упоминают UAF каждый раз, когда в отчете упоминается отказ в обслуживании (т.е. все говорят что-то вроде “эта уязвимость может быть использована для вызова отказа в обслуживании (использование после освобождения)”). Существует ли какой-то особый случай, который делает UAF приводящими к выполнению кода в контексте браузерного приложения, но не в каком-либо другом контексте? Я слышал, что ошибки, связанные с кучей (включая UAF), как правило, ненадежны из-за неизвестной компоновки кучи в момент эксплуатации, если только у атакующего нет метода “массирования” компоновки кучи, из которых самым распространенным является использование Javascript или какого-либо другого языка сценариев. Является ли эта причина (использование Javascript) причиной того, почему уязвимости использования после освобождения рассматриваются как уязвимости для выполнения кода в контексте браузера, но как отказ в обслуживании в контексте других программ?
На смежную тему, я слышал, что наличие какого-либо рода сценарной среды (Javascript, Flash и т.д.) требуется во многих случаях для эксплуатации ошибок утечки информации (например, утечка указателя для обхода ASLR), когда атакующий еще не имеет доступа к компьютеру, и атакуемая программа не может быть удаленно взаимодействована, например, когда атакующий пытается эксплуатировать уязвимость браузера. Это правда?
Наконец, в каких программах наблюдается наивысшая доля атак через форматные строки? Я попытался найти их для разнообразных широко используемых программ (разные браузеры, openssh, openvpn, openssl, Adobe Flash, движок Javascript V8 и различные http-серверы), и смог найти только две уязвимости через форматные строки, одна из которых могла быть использована только для чтения памяти, но не для выполнения произвольной записи. Затем я погуглил “format string cve details”, и почти каждый единственный результат на первых нескольких страницах был уязвимостью в PHP. Являются ли языки сценариев особенно уязвимыми к уязвимостям форматной строки?
Ответ или решение
Эксплуатируемость Уязвимостей Кучи
В рамках вашего исследования уязвимостей памяти, особенно уязвимостей типа "использование после освобождения" (use-after-free, UAF), важно рассмотреть контекст, в котором они проявляются, а также различия в эксплуатируемости этих уязвимостей между браузерами и другими приложениями, такими как Linux kernel.
Различия в Эксплуатируемости UAF
Уязвимости UAF действительно часто рассматриваются как способы вызова отказа в обслуживании (DoS) в контексте ядра Linux и других программ, тогда как в браузерной среде они могут привести к выполнению произвольного кода. Это связано с несколькими факторами:
-
Структура программы: В браузерах, таких как Chrome или Firefox, код часто работает в различных виртуальных машинах и контекстах, таких как JavaScript или WebAssembly. Это дает злоумышленнику больше возможностей для манипуляции с памятью через предоставленный ему интерфейс.
-
Управление памятью: В случаях, когда браузер управляет кучей через JavaScript, злоумышленник может влиять на расположение объектов в памяти, что позволяет более эффективно эксплуатировать UAF путем "сгибания" распределения кучи под свои нужды. Это дает возможность воспроизводить нежелательные состояния и манипулировать внутренними структурами данных приложений.
-
Сложность контекста: Браузеры должны обрабатывать множество различных исходных данных с неустойчивыми условиями выполнения, что повышает вероятность критических ошибок и, как следствие, возможности для успешной эксплуатации.
В то время как в других программных средах (например, со служебными приложениями) уязвимости UAF чаще реализуются в виде ошибок системы, что приводит к стабильным сбоям работы, в браузерах они могут использоваться для выполнения произвольного кода.
Необходимость Скриптовых Сред
По поводу вашего вопроса о необходимости скриптовых сред для эксплуатации утечек информации (инфо-утечек): это действительно может быть правдой. Скриптовые языки, такие как JavaScript, позволяют злоумышленникам динамически взаимодействовать с объектами, изменять их свойства в процессе выполнения и, тем самым, использовать утечки информации для обхода механизмов защиты, таких как ASLR. Без таких средств взаимодействия, атаки могут быть значительно более сложными и менее надежными.
Форматные Строки и Уязвимости
Что касается уязвимостей форматных строк, действительно, вы наблюдаетесь в том, что они гораздо чаще встречаются в контексте PHP и других языков программирования высокой абстракции по сравнению с языками низкого уровня, такими как C или C++. Однако это не означает, что языки низкого уровня менее уязвимы.
-
Объекты и данные: Программное обеспечение, которое работает с пользовательским вводом в качестве строки, часто подвержено этим атакам. PHP, использующий гибкие строки и контексты выполнения, часто компрометируется именно через уязвимости форматной строки.
-
Редкость в других языках: Языки, такие как C или C++, могут иметь более структурированные подходы к управлению памятью, что делает уязвимости форматных строк менее распространенными, однако они все еще остаются угрозой для спроектированных API.
-
Скриптовые и динамические языки: Скриптовые языки, которые широко используются для веб-разработки и обработки пользовательского ввода, на практике сталкиваются с большим количеством уязвимостей, включая форматные строки, из-за менее строгих подходов к типизации и валидации данных по сравнению с статически типизированными языками.
Заключение
Таким образом, различия в эксплуатируемости уязвимостей кучи, их влияние на код и недостатки в языках программирования раскрывают сложную зависимость между контекстом использования, механизмами взаимодействия и структурой программного обеспечения. Учитывая это, безопасности кода и правильному управлению памятью следует уделять пристальное внимание как в браузерах, так и в других приложениях с целью минимизации рисков.