Вместо вступления
Веб-браузеры являются неотъемлемой частью повседневной жизни каждого человека. Они часто используются для обеспечения безопасности и конфиденциальности, как для банковских транзакций, так и для проверки медицинских записей. К сожалению, современные веб-браузеры настолько сложны, что неизбежно имеют уязвимости (например, 25 миллионов строк кода в Chrome), и роль их в киберпространстве делает их уязвимыми. Таким образом, веб-браузеры являются естественной ареной для демонстрации продвинутых методов использования злоумышленниками и современных средств защиты от поставщиков браузеров. Возможно, веб-браузеры — отличное место для изучения последних проблем и технологий безопасности, но из-за их быстро меняющейся природы и сложной кодовой базы веб-браузеры все еще не так хороши, как кажется большинству исследователей безопасности. Чтобы восполнить этот пробел, в этой статье систематически описывается среда безопасности современных веб-браузеров путем изучения популярных типов уязвимостей безопасности, методов их использования и развертывании средств защиты.
Во-первых, сначала мы представляем унифицированную архитектуру, демонстрирующую дизайн безопасности четырех основных веб-браузеров.
Во-вторых, мы делимся выводами из почти 10-летнего лонгитюдного исследования уязвимостей браузеров.
В-третьих, мы представляем график и контекст плана реагирования и его эффективности.
В-четвертых, мы делимся уроками, извлеченными из эксплойтов полной цепочки, использованных в соревновании Pwn2Own 2020 года. Мы считаем, что это систематическое "причесывание" ключевых моментов может показать, как улучшить текущее состояние современных веб-браузеров и, что более важно, как создавать безопасное и трудновзламываемое программное обеспечение в будущем. Веб-браузеры играют неотъемлемую роль в современном образе жизни, связанном с Интернетом. Мы полагаемся на веб-браузеры, чтобы оплачивать ипотечные кредиты, планировать прививки и общаться с людьми по всему миру. Другими словами, веб-браузеры становятся привратниками киберпространства, и их незащищенность представляет серьезную угрозу безопасности, справедливости и конфиденциальности нашего общества. К сожалению, веб-браузеры всегда были наиболее привлекательными и ценными целями для кибератак — в 2021 году [58] 50% 0-day уязвимостей будут атаками на веб-браузеры, угрожающими Интернету. Каждому человеку.
Таким образом, современные веб-браузеры, естественно, являются полем битвы для злоумышленников, желающих взломать систему с помощью новых эксплойтов, и поставщиков браузеров, стремящихся обеспечить безопасность пользователей с помощью самых современных контрмер. Поставщики браузеров действительно являются важными игроками в продвижении современных методов обеспечения безопасности благодаря:
В этой статье делается смелая попытка систематически разобраться в среде безопасности современных веб-браузеров.
Во-первых, мы предоставляем унифицированную модель для четырех основных веб-браузеров с точки зрения безопасности, а затем сравниваем и сопоставляем их решения в области безопасности, используя предоставленные модели.
Во-вторых, на основе этой модели мы анализируем уязвимости безопасности, обнаруженные в каждом браузере с открытым исходным кодом за последние 10 лет, и показываем, как они связаны с разработкой новых контрмер, программ вознаграждения за обнаружение ошибок и известных методов эксплойтов.
В-третьих, основываясь на наших исследованиях, мы делимся своими знаниями и извлеченными уроками, чтобы вдохновлять исследователей и разработчиков, формирующих будущее веб-браузеров. Мы надеемся, что такая попытка поможет им получить всестороннее представление о подходе каждого поставщика, тем самым улучшив их структуру безопасности, чтобы свести к минимуму влияние на безопасность и поверхность атаки.
Три уникальные характеристики затрудняют систематизацию знаний о безопасности веб-браузеров.
Основное внимание в этом исследовании уделяется безопасности веб-браузера, включая защиту от собственных уязвимостей. Мы не рассматриваем другие проблемы безопасности, связанные с Интернетом, такие как проблемы безопасности веб-сайта или веб-сервера, такие как межсайтовый скриптинг (XSS), SQL-инъекция и т. д. Обратите внимание, что, хотя универсальный межсайтовый скриптинг (UXSS) звучит похоже на XSS, он часто возникает из-за проблем в реализации и дизайне браузеров и поэтому считается безопасностью веб-браузера (§III-E).
В этом разделе представлена унифицированная модель для каждого веб-браузера, позволяющая объективно сравнивать их подходы.
Современные веб-браузеры используют принцип наименьших привилегий и рассматривают процесс операционной системы как защищенный домен. Используя домены процессов, каждый веб-браузер можно описать тремя типами процессов, а именно БРАУЗЕРНЫЕ ПРОЦЕССЫ (обозначено зеленым), ПРОЦЕСС РЕНДЕРИНГА пурпурным, фактически в фиолетовой части изображения) и СПЕЦИФИНЫЕ ПРОЦЕССЫ (отмечены желтым цветом), как показано на рисунке ниже..
Все браузеры развертывают песочницу (розовая область), чтобы ограничить средство визуализации, и подробный метод песочницы зависит от базовой ОС. Существуют тонкие, но важные различия между браузерами.
Браузерные процессы - при запуске веб-браузера процесс браузера запускается с тем же уровнем привилегий, что и пользователь (т. е. с более высокими привилегиями), и передает файл конфигурации песочницы в операционную систему, чтобы ограничить привилегии других процессов (т. е. с более низкими привилегиями). Он управляет всеми дочерними процессами (такими как средство визуализации) и является единственным процессом, который напрямую взаимодействует с пользователем через системные вызовы (и пользовательский интерфейс).
Процес рендеринга - этот процесс отвечает за синтаксический анализ и отображение ненадежного веб-контента. Постоянно увеличивающееся количество типов данных в Интернете привело к тому, что процессы рендеринга содержат широкий спектр компонентов, таких как синтаксические анализаторы мультимедиа, DOM и JS-движки. Поскольку они являются основным источником ошибок браузера, они ограничены изолированными программными средами (см. §II-C). Процессы визуализации обычно создаются для каждой вкладки браузера или веб-страницы. Политики изоляции для каждого средства визуализации различаются в зависимости от политик безопасности или возможностей каждого веб-браузера (например, изоляция сайта), ресурсов, доступных во время выполнения (например, нехватка памяти на мобильных устройствах) и даже конфигурации пользователя.
Другие процессы - Архитектура современных браузеров модульная. Модульный дизайн позволяет браузерам иметь разные уровни привилегий в зависимости от роли процесса. Службы, которые взаимодействуют с внешними драйверами (например, сетевые или графические процессы), выделяются как отдельные процессы, что обеспечивает более строгую песочницу для процессов, которым не требуется такой доступ (например, процессы рендеринга). Веб-браузеры также обычно размещают расширения и плагины в отдельных процессах. Это защищает плагины с более высокими уровнями привилегий от вредоносного веб-контента и защищает браузер от взлома в случае вредоносных плагинов.
Межпроцессное взаимодействие (IPC) - поскольку эти процессы не имеют прямого доступа к памяти друг друга, они всегда взаимодействуют через канал IPC, предоставляемый операционной системой, и связь обычно осуществляется через процесс браузера (прокси). Другими словами, процесс браузера действует как реляционный монитор, ограничивая прямой доступ к важным данным или привилегированным операциям (например, к файлам cookie или системным вызовам) из других процессов. Из-за этой многопроцессорной архитектуры атака всегда запускается из процесса с низким уровнем привилегий, такого как процесс рендеринга, и цель злоумышленника — взломать процесс браузера, работающий с привилегиями пользователя. В то же время он восстанавливается после сбоев, вызванных безобидными ошибками в процессе рендеринга, что делает браузер устойчивым к проблемам со стабильностью.
Same Origin Policy, в переводе с англ. — «Принцип одинакового источника» . На самом деле веб-сайты состоят из большого количества контента из разных источников, например, с использованием CDN для общих библиотек JavaScript, встраивания внешних сайтов через iframe или включения кнопок «Нравится» в социальных сетях. Сложность веб-сайтов способствовала многочисленным политикам безопасности и уникальным функциям каждого веб-браузера. В зависимости от происхождения каждого веб-сайта [94] процесс браузера и процесс рендеринга ограничивают ресурсы (например, файлы cookie), с которыми разрешено взаимодействовать веб-странице, что известно как политика единого происхождения (SOP)
Обсуждаемые до сих пор конструкции в равной степени применимы ко всем четырем основным браузерам. Однако, некоторые детали реализации будут различаться в зависимости от дизайна браузера и лежащей в его основе операционной системы. Например, процесс графического процессора в Chrome и Safari отделен от процесса рендеринга и использует профиль песочницы, чтобы позволить им получить доступ к платформе 3D API. Кроме того, в Chrome, Firefox и Safari есть отдельный процесс для веб-служб, в то время как веб-службы Chrome хранятся вне песочницы. В настоящее время команда Chrome внедряет песочницу для своих веб-сервисов. Песочница действительно защищает браузеры, однако с появлением атак Universal Cross-Site Scripting (UXSS) злоумышленники могут красть пользовательские данные из песочницы. Чтобы справиться с такими атаками, команда Chrome предложила изоляцию сайтов, чтобы еще больше разделить разные источники сайтов на разные процессы. Создается выделенный процесс для каждого источника сайта, поэтому нет неявного совместного использования между разными источниками сайтов. Изоляция сайта является эффективной мерой для решения проблемы UXSS, а также полезна для предотвращения аппаратных атак временного выполнения. У Firefox есть аналогичный проект под названием Fission, который был выпущен в Firefox_88_Beta.
JavaScript
Движок JavaScript лежит в основе современных браузеров, он преобразует код JavaScript в машинный код. Основные браузеры используют Just-In-Time (JIT) для ускорения выполнения кода. Кроме того, компилятор JIT моделирует результаты и побочные эффекты всех операций и запускает различные процессы анализа для оптимизации кода. Если какой-либо из них пойдет не так, будет сгенерирован и выполнен собственный код с проблемами повреждения памяти, что может привести к серьезным проблемам с безопасностью. Хотя каждый движок имеет различную реализацию, они используют схожие принципы проектирования и имеют общую поверхность атаки. Таким образом, злоумышленники могут создавать общие примитивы атаки для разных движков, такие как примитивы fakeobj и addrof и преобразование типов элементов. Механизмы JavaScript также используются вне браузера (например, Node.js использует V8), что усиливает влияние уязвимостей безопасности в механизмах JavaScript. Мы обсуждаем проблемы, вызванные браузерными движками того же типа, в §VI-A.
Рендеринг
Механизм рендеринга отвечает за интерпретацию ресурсов и рендеринг веб-страниц. Каждый из четырех больших браузеров имеет свой собственный движок рендеринга: Safari использует WebKit, Chrome использует Blink (производный от WebKit), Firefox использует Gecko, Edge использует Blink (заменяет EdgeHTML). Веб-стандарты служат базовыми спецификациями и ссылками для поставщиков браузеров при реализации своих механизмов рендеринга. По мере того, как веб-стандарты продолжают развивать новые функции, механизмы рендеринга также претерпевают быстрые изменения, т. е. внедряются новые функции или удаляются устаревшие функции. Из-за различных процессов принятия решений и стратегий реализации функции, реализованные в механизмах рендеринга разных браузеров, сильно различаются, и, следовательно, поверхность атаки также различна.
Таблица I. Сравнение песочниц (Chrome, Firefox, Edge, Safari; в Windows, Linux, MacOS)
В таблице I мы делим примитивы песочницы на три категории в зависимости от их роли:
Мы также сравниваем возможности песочницы разных операционных систем (например, Windows, Linux и macOS).
Эксплуотация браузера
Целью эксплуатации браузера является кража конфиденциальных данных его пользователей или установка вредоносных программ для дальнейших действий. Злоумышленники могут выполнять такие атаки, как UXSS, чтобы напрямую украсть данные или выполнить код, а затем попытаться выйти из песочницы. Злоумышленники могут попытаться получить системные привилегии для выхода из песочницы, атакуя ядро, что выходит за рамки этой статьи. Благодаря различным обходным путям злоумышленнику необходимо связать вместе несколько ошибок (например, использовать 4 комбинации ошибок до выхода из песочницы, чтобы добиться произвольного выполнения. Даже после захвата потока управления, поскольку процесс рендеринга выполняется внутри песочницы, злоумышленнику необходимо найти еще один набор ошибок в прокси-процессе для выхода из песочницы. В зависимости от имеющихся в арсенале уязвимостей злоумышленники часто пытаются вырваться из «песочницы», используя ошибки в системных службах, драйверах или ядре, а не в прокси-процессах.
В этом разделе мы сначала проводим статистическое исследование общедоступных уязвимостей браузеров за последнее десятилетие, чтобы определить тенденции, а затем описываем основные типы уязвимостей (например, ошибки движка JavaScript) и соответствующие ответы, выпущенные их поставщиками.
1. Регулярно обновляемые бюллетени безопасности от поставщиков браузеров .
2. Публичный трекер проблем, опубликованный вендором .
3. Репозитории с открытым исходным кодом имеют обычную практику отправки исправлений ошибок к опубликованным уязвимостям .
4. Отчеты CVE в Национальной базе данных уязвимостей (NVD) .
5. Эксплойты безопасности, используемые в реальном мире, такие как ошибка, используемая в Pwn2Own [61], и отчеты Google Project Zero.
Рисунок ниже показывает резкое увеличение числа уязвимостей безопасности во всех браузерах, особенно с 2010 года. Мы считаем, что это увеличение числа уязвимостей связано с растущим кодом браузера, поскольку постоянно добавляются новые функции. Кроме того, значительную роль сыграли достижения в методах поиска уязвимостей после 2010 года
Векторы динамических атак
Из-за огромного размера и постоянно меняющейся природы браузеров векторы атак постоянно меняются. Для браузеров с открытым исходным кодом Firefox и Chromium мы сопоставляем ошибки с соответствующими хост-компонентами и классами ошибок, как показано на рисунке 4. Для обоих браузеров мы использовали назначаемые разработчиком признаки для сопоставления ошибок с компонентами их основного браузера и описания уязвимостей с сопоставлением ключевых слов для их классификации.
Ошибки рендерера преобладают как в Firefox, так и в Chromium, потому что рендерер — это сердце браузера. Увеличение числа уязвимостей, связанных с спуфингом URL-адресов, в Chromium с 2016 года показывает, насколько легко найти уязвимости в ранее неисследованных областях. Ошибки памяти в целом и ошибки UAF в частности по-прежнему являются самой большой общей чертой обоих браузеров.
Еще один общий вывод заключается в том, что два браузера имели разное количество уязвимостей в двух областях на протяжении многих лет. Например, для компонентов с ошибками в Chromium в последнее время было больше эксплойтов DOM и HTML, но количество эксплойтов DOM и HTML в Firefox уменьшается. Что касается категории ошибок, большинство ошибок в Chromium в 2019 году были классифицированы как уязвимости UAF, OOB и спуфинга URL, но описание распространения ошибок в Firefox на протяжении многих лет было относительно одинаковым. Следовательно, эта разница не только интуитивно показывает изменяющиеся векторы атак, но и изменения в стратегиях классификации уязвимостей безопасности разных браузеров.
Усилия браузера по борьбе с ошибками также можно показать на графике. Изоляция сайта Chromium в ответ на уязвимость UXSS привела к значительному сокращению вышеуказанных уязвимостей после того, как в 2017 году была реализована изоляция сайта. Некоторые типы уязвимостей остаются основными источниками ошибок, например компоненты DOM и HTML
Уязвимости безопасности памяти являются критическими и доминирующими в браузерах. Например, Chromium помечает более 70% уязвимостей высокой степени серьезности как проблемы с безопасностью памяти, половина из которых — ошибки UAF. Как показано на рисунке, несмотря на контрмеры, в последнее десятилетие доминировали уязвимости безопасности памяти. Недавно были предприняты попытки переписать браузеры на безопасных для памяти языках, таких как Rust, чтобы уменьшить уязвимости, связанные с безопасностью памяти. Например, Mozilla переписывает части Firefox на Rust в рамках проекта под названием Oxidation. По состоянию на 2020 год проект Oxidation заменил 12% компонентов Firefox на Rust (написан эквивалентный модуль). Пять замененных подкомпонентов относятся к компоненту синтаксического анализа мультимедиа средства визуализации. Мы также отображаем количество дыр безопасности в памяти в компоненте анализа мультимедиа средства визуализации на рис ниже. Понятно, что с момента запуска Project Oxidation в 2015 году количество ошибок безопасности памяти в Firefox немного, но неуклонно снижается, при этом значительно меньше ошибок безопасности памяти в медиа-компоненте рендерера. Несмотря на многочисленные попытки производителей браузеров решить проблему безопасности памяти, ни одна из них не дала такого резкого эффекта, как Oxidation в Firefox.
Количество уязвимостей памяти и других уязвимостей в Firefox и других браузерах. RM-Mem — это количество уязвимостей безопасности памяти в компоненте парсинга мультимедиа средства визуализации Firefox, описывающее тенденцию к снижению с 2015 года после частичной перезаписи в Rust.
Использование языка, безопасного для памяти, может эффективно уменьшить уязвимости безопасности памяти.
Как показано на рисунке выше, использование Rust в Firefox эффективно для уменьшения уязвимостей безопасности памяти. Хотя это требует больших усилий, это фундаментальный подход, и именно он с наибольшей вероятностью устранит уязвимости безопасности памяти. Мы рекомендуем другим производителям браузеров следовать этой лучшей практике и постепенно переводить свои браузеры на безопасный для памяти язык.
Тенденции в отношении используемых компонентов браузера и категорий ошибок. Данные включают ошибки во всех браузерах. В строке указано совокупное количество ошибок. Ошибки движка JavaScript и UAF доминируют над используемыми компонентами ошибок и типами уязвимостей, соответственно.
Для компонентов браузера преобладали уязвимости DOM, пока в 2017 году их не заменили уязвимости движка JS. Тем не менее, уязвимости DOM сохраняются и сегодня и показывают медленный и устойчивый рост даже после того, как было добавлено множество мер по их устранению. Для типов уязвимостей, несмотря на все меры противодействия, ошибок безопасности памяти, таких как уязвимости UAF, в фактической эксплуатации по-прежнему больше, чем других типов уязвимостей. Интересным открытием стала соответствующая тенденция в категориях и компонентах выявленных уязвимостей. Для большинства линий на графике мы видим довольно резкий рост в первые годы, но более медленный рост после этого (за исключением ошибок движка JavaScript). Эта тенденция является визуальным представлением усилий злоумышленников по поиску и изучению новых методов атак, а также ответных мер поставщиков по устранению и устранению новых уязвимостей.
После ужесточения распределителя кучи этот эксплойт стал более сложным или невозможным, в основном из-за разделения объектов JS в куче. Однако крупномасштабные фаззеры, такие как ClusterFuzz, также обнаружили много уязвимостей парсера. Поставщики браузеров работают над изолированием сетевого кода и переписыванием кода браузера на безопасных для памяти языках, таких как Rust. В результате таких уязвимостей становится меньше, и их сложнее использовать. Тем не менее, при анализе данных существуют зависимости от нескольких сторонних библиотек, поэтому обновления безопасности необходимо строго контролировать.
Хотя фаззеры продолжают выявлять новые уязвимости DOM, из-за возросшей сложности эксплуатации уязвимостей DOM, недавно известные полноценные эксплойты в дикой природе, как правило, используются на деле уязвимости в других компонентах.
Контрмеры UAF эффективны в снижении эксплуатации уязвимостей DOM.
Поскольку ошибки DOM в значительной степени зависят от проблем UAF, они в основном решаются с помощью контрмер UAF. Обычные методы эксплуатации, основанные на обфускации типа указателя, стали невыполнимыми, поскольку куча разделяется по типам объектов, и нет общедоступной альтернативной техники. В результате, использование уязвимостей DOM больше не является предпочтительным методом взлома рендереров.
Компилятор JIT в движке JS использует спекулятивную оптимизацию. Уязвимости в этих механизмах оптимизации являются более серьезными, чем традиционные уязвимости безопасности памяти (такие как повторное использование после освобождения или переполнение буфера), потому что они неустранимы, но предоставляют злоумышленникам мощные примитивы эксплойта. С точки зрения высокого уровня ошибки движка JS можно в основном разделить на четыре категории: - Уязвимости JIT-анализа: уязвимости в процессе анализа или модели JIT-компилятора. Такие уязвимости имеют наибольшую возможность использования и влияние. - Уязвимости мутации/генерации JIT-кода: уязвимости в процессе манипулирования графами JIT или генерации кода. - Ошибки побочных эффектов, не связанные с JIT: ошибки побочных эффектов во встроенных функциях JavaScript, в основном связанные с быстрым путем. - Уязвимости, не связанные с JIT Legacy, приводящие к повреждению памяти: другие уязвимости, приводящие к повреждению памяти, не подпадающие под указанные выше категории.
Мы изучили 45 эксплуатируемых уязвимостей; есть 13 уязвимостей JIT-анализа, 9 уязвимостей с побочными эффектами, не связанных с JIT, и 11 устаревших уязвимостей, связанных с повреждением памяти, но нет уязвимостей JIT-кода, связанных с изменением/генерацией кода. Мы подозреваем, что это связано с тем, что эту уязвимость сложно использовать. Большинство ошибок в JIT-компиляторах — это логические ошибки. Поскольку это инфраструктура компилятора, логические уязвимости могут быть преувеличены как дыры безопасности памяти в коде, скомпилированном JIT. Поэтому сложно сделать общие меры по устранению ошибок JIT.
Меры противодействия:
Примитивное исключение
Этот тип контрмер предназначен для предотвращения подделки злоумышленниками допустимых объектов с помощью примитива fakeobj. Например, в JavaScriptCore рандомизация StructureID использует 7 случайных битов энтропии для кодирования StructureID, что затрудняет угадывание злоумышленниками. Поскольку StructureID представляет тип и форму объекта JS, угадывание неправильного StructureID сделает форму недействительной, а доступ к ней в конечном итоге приведет к сбою процесса
Изоляция адресного пространства
Этот тип контрмер изолирует различные объекты, чтобы предотвратить их подделку или перезапись. GigaCage — это область виртуальной памяти объемом 4 ГБ, которая разделяет разные объекты на разные кучи (или виды кучи). Основная идея состоит в том, чтобы предотвратить доступ к памяти между разными кучами и использовать относительные смещения от базового адреса кучи для поиска объектов GigaCaged вместо абсолютных адресов. Таким образом, даже если указатель поврежден, он не может указывать ни на что за пределами исходной кучи. PACCage используется для защиты указателя буфера резервного хранилища TypedArray и использует код аутентификации указателя (PAC) поверх GigaCage для дальнейшего повышения безопасности. Песочница Chrome V8 Heap является экспериментальной и ее цель аналогична GigaCage, но она пытается защитить внешние указатели с помощью отдельной таблицы указателей, после чего злоумышленник не может создавать произвольные значения для внешних указателей.
Защита от перезаписи
Это стандартный механизм защиты, предотвращающий внедрение злоумышленниками произвольного исполняемого кода, и его можно рассматривать как последнюю линию защиты в контексте эксплойтов браузера.
и неразборчивые инструкции кадра вызова
Внутренняя рандомизация - Злоумышленник также может использовать относительное расположение инструкций друг к другу или предсказуемое смещение от базового адреса. Некоторые контрмеры, направленные на диверсификацию компоновки кода JIT, включают: рандомизацию относительных смещений между различными парами инструкций и случайную вставку свободного места перед первой кодовой единицей
Хотя проводятся эксперименты по предотвращению определенных типов уязвимостей (§IV-D), охватить их все сложно. Поэтому контрмеры в движках JS сосредоточены на устранении примитивов атаки. Недавно команда Edge добавила новую функцию безопасности под названием Super Duper Secure Mode (SDSM), которая фактически отключает JIT-компиляцию. Пользователи могут отключить JIT на менее посещаемых сайтах. Несмотря на некоторую потерю производительности, это отличный способ уменьшить поверхность атаки. Несмотря на то, что было введено несколько контрмер, JCRA по-прежнему полезен, поскольку поставщик не инвестировал много ресурсов для реализации или поддержания контрмер.
Бороться с уязвимостями JS-движков очень сложно. Уязвимости движка JavaScript, особенно уязвимости JIT-компилятора, являются очень мощными, поскольку злоумышленник может выпустить код с проблемами повреждения памяти. Поскольку бороться с логическими уязвимостями зачастую сложно, многие контрмеры направлены на предотвращение эскалации эксплойтов на языке оригинала. В результате поставщики часто внедряют меры по снижению риска, которые прерывают путь эксплойта, и постоянно совершенствуют их для предотвращения будущих атак.
Изоляция сайта — одна из наиболее важных контрмер против UXSS-атак. Изоляция сайта обеспечивает соблюдение SOP на уровне процесса, что делает невозможным использование большинства существующих уязвимостей UXSS. После постепенного применения изоляции сайтов после 2017 года количество зарегистрированных уязвимостей UXSS значительно уменьшилось, как показано на рисунке 6. Но уязвимости UXSS в сторонних расширениях все еще существуют; в популярных расширениях было обнаружено множество уязвимостей UXSS, которые позволяют злоумышленникам обходить изоляцию сайта и красть учетные данные пользователей. Изоляция сайта является эффективной мерой по снижению уязвимостей UXSS. Однако только Chrome и Firefox развернули изоляцию сайта, поскольку это требует значительных инженерных работ.
Песочница имеет решающее значение для безопасности браузера, поскольку она ограничивает влияние уязвимостей в процессе рендеринга, который содержит различные компоненты, подверженные проблемам. За исключением случаев, подобных UXSS, злоумышленникам необходимо использовать уязвимости в ядре, системных службах или процессах браузера, чтобы выйти из песочницы рендерера. Таким образом, это значительно поднимает планку для атаки, поскольку злоумышленникам необходимо использовать оба компонента (рендерер и песочницу) для выполнения атаки 0-day по полной цепочке.
Блокировка Win32k - Поскольку большинство уязвимостей ядра Windows существует в системных вызовах Win32k, в 2012 году Microsoft ввела политику отключения системных вызовов — Win32k Lockdown для Windows. Разработчики Windows-приложений могут полностью блокировать доступ к таблице системных вызовов Win32k, значительно уменьшая поверхность атаки. Edge, Chrome и Firefox уже используют этот механизм для защиты браузера. Поэтому реализация выхода из песочницы из процесса визуализации становится более сложной.
Песочница на базе гипервизора - Application Guard в Защитнике Windows (WDAG) был представлен Microsoft для изоляции ненадежных веб-сайтов или ресурсов (например, файлов) в корпоративных сценариях. WDAG использует Hyper-V для создания нового экземпляра Windows на аппаратном уровне, который включает в себя отдельную копию ядра и минимальные службы платформы Windows, чтобы обеспечить правильную работу браузера Edge. WDAG реализован в Edge для предотвращения расширенных атак, которые могут обойти изолированную программную среду браузера. Благодаря WDAG злоумышленникам необходимо избегать песочниц и виртуальных машин Hyper-V.
Улучшенное распределение
По соображениям производительности и безопасности браузеры используют специализированные распределители кучи для многих объектов. Эти распределители используют особую конструкцию, помогающую снизить ущерб за счет ограничения примитивов атаки.
Изолированная куча: Изоляция кучи является эффективной защитой от атак UAF, которые перерастают в атаки обфускации типов. Изолируя объекты на основе:
1) типа;
2) уровня риска безопасности (например, встраивание указателей на v-таблицы);
3) доступности JavaScript (например, ArrayBuffer), изоляция кучи эффективно повышает порог эксплуатации уязвимости UAF. Изоляция не позволяет злоумышленнику повторно объявить освобожденный объект, используя объект с другим расположением, что является классической операцией в эксплойтах UAF браузера.
Современные браузеры реализуют базовый уровень разделения кучи между JavaScript-доступными объектами (JavaScript) и другими объектами. Однако все еще возможно вызвать путаницу типов между объектами в одной и той же куче, но других типов с помощью UAF. Чтобы предотвратить такие атаки, Safari и Firefox вводят отдельные кучи для каждого типа в данной категории, что обеспечивает более тонкую изоляцию. В результате, не существует общедоступного универсального эксплойта для эксплуатации уязвимостей UAF во всех браузерах.
Отложенное освобождение: Другая контрмера, отложенное освобождение, эффективно затрудняет использование уязвимостей UAF, но этот метод не ограничивает утилизацию висячих указателей. Браузеры используют различные алгоритмы сбора мусора (GC) для освобождения объектов без ссылок на куче; некоторые варианты алгоритма GC дополнительно сканируют стек и кучу на предмет ссылок, которые могли быть пропущены, что известно как консервативное сканирование или отложенное освобождение. Примечательно, что Firefox отказался от этой стратегии в пользу точного укоренения и написал инструмент статического анализа для поиска небезопасного использования ссылок в стеке. Chrome имеет аналогичный инструмент, но он применяется только в определенных регионах. Однако отложенный выпуск вводит примитивы побочных каналов, которые могут быть использованы для поражения механизма ASLR, поскольку он не может отличить указатели на кучу от целых чисел, управляемых пользователем.
Защита метаданных кучи: Защита метаданных кучи - это метод проверки части метаданных блока кучи для предотвращения повреждения кучи и распространения тихих уязвимостей в куче. Например, распределитель кучи может поместить случайное значение перед опасной структурой данных для обнаружения уязвимостей кучи, а PartitionAlloc в Chrome удаляет встроенные метаданные и помещает страницу защиты, чтобы предотвратить линейные переполнения кучи от перезаписи метаданных. Существуют также некоторые усилия по защите метаданных на уровне ОС.
Другие средства защиты кучи: Отравление фреймов в Firefox освобождает блоки памяти, адреса которых указывают на недоступные страницы памяти. Аналогично, в Edge это делается путем заполнения блока кучи нулями при его освобождении. GWP-ASan в Chrome размещает небольшую случайную часть выделенных объектов до/после защиты страницы и освобождает всю страницу при освобождении блока для обнаружения ошибок кучи в естественных условиях.
Целостность потока управления
Поскольку злоумышленники часто манипулируют значениями указателей команд для достижения выполнения кода, целостность потока управления обеспечивается для предотвращения перехвата потока управления, что затрудняет атаки. Инфраструктура компилятора, операционная система и аппаратная поддержка обеспечивают большинство смягчений в этой категории, таких как защита таблиц виртуальных функций путем введения канареечных значений и разрешение перечисления косвенных ветвей путем проверки целевого адреса.
Ведется работа по предотвращению произвольной записи в память для модификации областей кода, которые могут быть выполнены злоумышленником. На основе аппаратной поддержки браузеры могут применять дополнительные контрмеры без существенного снижения производительности, например, добавление проверок целостности указателей с помощью PAC на ARM64, дополнительная защита W ⊕ X и APRR для JIT-компилированного кода с помощью Intel MPK.
Сторонние (боковые) каналы
Браузеры также уязвимы для атак по боковым каналам. Исследования на сегодняшний день показали, что конфиденциальная информация в браузерах может быть получена из:
1. состояния микроархитектуры
2. графических процессоров;
3. каналов синхронизации с плавающей запятой;
4. каналов измерения, специфичных для браузера
Исследователи представили защитные механизмы] для защиты браузеров от атак по боковым каналам, такие как DeterFox и FuzzyFox . Кроме того, производители браузеров внедрили средства защиты, которые делятся на следующие две категории.
Уменьшение разрешения таймера: поскольку большинство атак опирается на точное определение времени, чтобы затруднить обнаружение небольших временных различий, производители браузеров уменьшили разрешение точных таймеров (например, performance.now()) и ввели случайный джиттер для предотвращения восстановления разрешения. После обнаружения Spectre и Meltdown производитель еще больше снизил точность таймера. Поскольку SharedArrayBuffer мог использоваться для создания таймеров высокого разрешения, SharedArrayBuffer был отключен во всех современных браузерах вскоре после обнаружения Spectre.
Предотвращение совместного использования ресурсов: Еще одна техника противодействия заключается в предотвращении совместного использования ресурсов жертвой и злоумышленником. Изоляция сайта эффективно справляется с переходным выполнением на основе Javascript. Политики Cross-Origin-Opener-Policy (COOP) и Cross-Origin-Embedder-Policy (COEP) были введены для создания среды междоменной изоляции. COOP позволяет веб-сайтам включать заголовки ответов в документы верхнего уровня, гарантируя, что междоменные документы не имеют общего просмотра. COEP предотвращает загрузку страницей любого междоменного ресурса, который не был явно разрешен этой странице. Они обеспечиваются с помощью HTTP-заголовков и доступны в Chrome 83, Firefox 79 и Edge 83, в то время как по состоянию на ноябрь 2021 года Safari их не поддерживает.
Использование SharedArrayBuffer было вновь включено в Chrome и Firefox после внедрения изоляции сайтов и COOP/COEP. Однако одно исследование показало, что повторное введение SharedArrayBuffer увеличило пропускную способность скрытого канала в 2 000 и 800 000 раз соответственно. Две недавние работы показывают, что, несмотря на изоляцию сайтов в Chrome, злоумышленники все равно могут получить доступ к конфиденциальной информации в разных доменах.
Другие контрмеры
Смягчение UAF: Для устранения основной причины проблем UAF, не покрываемых сбором мусора или другими мерами безопасности, команда Chrome ввела термин MiraclePtr, который обозначает набор алгоритмов, позволяющих обернуть необработанные указатели в C/C++ так, чтобы их нельзя было использовать через UAF. Ожидается, что MiraclePtr вскоре Ожидается, что MiraclePtr будет введен в использование в ближайшее время.
Улучшение безопасности памяти: команда Chrome изучила усовершенствования в кодовой базе C++, которые могут устранить или уменьшить конкретные типы уязвимостей путем ограничения использования специфичных для языка функций (например, исключений C++ ) и внедрения классов-оберток вокруг целочисленных операций.
Улучшение JIT-компилятора: Было предпринято много усилий для защиты от опасных операций оптимизации в JIT-компиляторе. Например, во многих эксплойтах для устранения "кажущихся излишними" проверок границ используется метод bounds check elimination. Чтобы решить эту проблему, команда Chrome ввела исправление, которое помечает такие проверки как "прерывание", а не просто удаляет их. Кроме того, чтобы сделать генерацию байткода стандартных функций JS менее подверженной ошибкам, команда Chrome разработала специфический для данной области язык Torque, который заменяет существующую реализацию C++ и уменьшает количество LoCs.
Совместные усилия по реагированию могут принести пользу.
Когда один поставщик внедряет контрмеру, другие могут последовать его примеру. В таблице IV мы видим, что многочисленные контрмеры были приняты несколькими браузерами. Если уязвимость обнаружена в одном браузере, производитель может быстро поделиться информацией с другими производителями и вместе они могут использовать свои коллективные знания для создания лучшего обходного пути. В случае с атакой Spectre/Meltdown хорошим примером совместных усилий является совместная работа производителей браузеров над разработкой плана по снижению непосредственной угрозы.
Тематическое исследование: Эксплуатация всей цепи
Поскольку современные браузеры имеют различные функции безопасности, браузерные эксплойты часто требуют соединения нескольких атак, чтобы в конечном итоге выполнить вредоносное действие. Объединение всех этих этапов часто называют полноцепочечной эксплуатацией. В качестве показательного примера эксплуатации браузера с полной цепочкой мы проанализировали успешную атаку на Safari в соревновании Pwn2Own 2020 года.
Эта атака проникла в процесс рендеринга, начавшись с уязвимости оптимизации JIT-компилятора: компилятор DFG в Safari JavaScript renderer неправильно моделирует побочные эффекты оператора "in", когда выполняется специальное условие для прокси-объектов. Эта уязвимость позволяет злоумышленнику сконструировать стандартный примитив addrof/fakeobj для произвольного чтения/записи памяти и, в конечном итоге, выполнения произвольного кода. Для того, чтобы создать действительный объект с помощью fakeobj, злоумышленники используют хорошо известную технику обхода аутентификации формы объекта (рандомизация идентификатора структуры ). После подделки объекта JavaScript они используют известную технику для обхода изоляции адресного пространства (Gigacage) и получения произвольных примитивов чтения/записи в процессе рендеринга.
Если процесс рендеринга скомпрометирован, следующим шагом будет побег из песочницы, что гораздо сложнее. В этой атаке злоумышленник ловко соединил несколько логических/памятных эксплойтов, чтобы избежать "песочницы". Сначала злоумышленник дополнительно получает выполнение произвольного кода от службы CVMServer XPC (часть встроенного фреймворка OpenGL), которая находится в песочнице, но имеет возможность создавать символические ссылки, чего нет у процесса рендеринга. Кроме того, Safari имеет IPC-метод didFailProvisionalLoad(), который может запускать произвольные приложения, если предоставлена символическая ссылка на папку приложения. Объединив их, злоумышленник может запустить любое приложение через Safari. В этот момент песочница успешно нарушена, поскольку они могут выполнять произвольные приложения за пределами песочницы рендерера, подобно пользователю, запустившему Safari.
Наше резюме примера Pwn2Own является конкретным, но действенным. Исходя из этого, мы описываем эксплойт для браузера с полной цепочкой в более общем виде. Во-первых, для поиска уязвимостей в рендере можно использовать методы fuzz-тестирования или вручную просмотреть исходный код браузера. Поиск эксплуатируемых ошибок будет одним из самых сложных этапов. После обнаружения таких уязвимостей следующим шагом является реализация примитивов выполнения произвольного кода в контексте процесса рендеринга. Однако получение контроля над рендерером - это только начало, поскольку рендерер ограничен механизмом "песочницы". Чтобы прорваться через "песочницу", злоумышленники обычно нацеливаются на дефекты в процессе браузера, ядре операционной системы или протоколе IPC. В отличие от атаки на рендерер, для побега из песочницы обычно требуется связать уязвимости логики высокого уровня с несколькими компонентами системы. После выхода из "песочницы" злоумышленник может выполнить произвольную программу с тем же уровнем безопасности, что и браузер, что позволяет осуществить атаку по всей цепочке.
Обсуждение
В этом разделе мы обсудим несколько аспектов, связанных с безопасностью браузера.
Проблемы в патчах
Благодаря существованию публичных репозиториев и трекеров проблем, исправления в браузерах с открытым исходным кодом могут быть сначала выложены в открытый доступ, до того как новые версии будут завершены и выпущены для конечных пользователей, что позволяет злоумышленникам оценить возможность использования исправлений. Например, iOS Safari эксплуатировался из-за полуторамесячного отсутствия патча. Чтобы устранить этот пробел, Chrome ввел обновления безопасности раз в две недели и сократил цикл выпуска с шести до четырех недель. Firefox не позволяет размещать исправления безопасности в хранилище до их выпуска и рекомендует не включать информацию об уязвимостях в заявки на исправления.
Однородность браузерных движков
Многие "вторичные браузеры" используют тот же браузерный движок, что и ведущий браузер (например, Chrome V8). В результате уязвимости в одном движке браузера могут повлиять на другие браузеры с общим движком. Из 15 самых популярных браузеров 11 основаны на движке Chrome (включая Microsoft Edge ). Когда выходит новая версия Chrome с исправлениями ошибок, они не сразу применяются во вторичных браузерах; существует временной лаг, прежде чем вторичные браузеры интегрируют их.
В зависимости от истории выпуска суббраузера, существует временной лаг до применения выпущенных исправлений безопасности, что обеспечивает окно атаки для злоумышленников. Например, уязвимость WebKit может быть использована на прошивке PlayStation через несколько месяцев после того, как о ней было сообщено в системе отслеживания ошибок WebKit. Это также является проблемой в Android, где приложения поставляются с встроенными движками рендеринга, например, об уязвимости UXSS было сообщено в интернет-браузере Samsung Internet (Samsung Internet) примерно через месяц после сообщения о ней в Chromium. Apple смогла использовать эту уязвимость, заставив все приложения использовать библиотеку WebKit, предоставляемую ОС, и запретив использование библиотеки WebKit. несоответствующие приложения в своем App Store, чтобы решить эту проблему в iOS.
Кроме того, использование компонентов веб-браузера, таких как рендереры и движки JavaScript, распространяется и на приложения, использующие такие фреймворки, как Electron и Android WebView. Кроме того, Node.js и Deno используют движок V8 от Google для включения JavaScript вне контекста браузера (например, для реализации веб-сервера). В результате уязвимости и эксплойты в движке браузера влияют не только на сам браузер, но и на необходимость создания более совершенных защитных механизмов для предотвращения катастрофических последствий.
Однородность движков браузеров вызывает серьезные проблемы; необходимы более совершенные исправления Из-за однородности браузерных движков уязвимости в одном браузерном движке могут повлиять на многие другие браузеры и приложения. Мы рекомендуем ведущим браузерам (например, Chrome) сделать свои движки JavaScript доступными для других приложений в виде общих библиотек, чтобы исправления было легче развертывать через обновления по сети, а не вручную интегрированные исправления.
Средства обнаружения уязвимостей
Было приложено много усилий для разработки современных инструментов для обнаружения ошибок в браузерных движках, и эти инструменты можно разделить на две основные категории: fuzzing и статический анализ.
Фаззинг - одна из самых эффективных стратегий поиска ошибок, которая используется для поиска ошибок в браузерах с 2012 года. Safari и Edge (на базе ChakraCore и V8), а также их ключевые приемы. Эти фаззеры выбирают между двумя классическими моделями: мутационный фаззинг (например, Montage ) и генерационный фаззинг (например, CodeAlchemist ). Некоторые фаззеры, такие как Lang-Fuzz и DIE, используют смесь этих двух моделей, а также обратную связь по покрытию. Создание синтаксически и семантически осведомленных входов, таких как DIE и LangFuzz, полезно для генерации большего количества сбоев. Некоторые усилия, направленные на промышленную природу нечетких браузеров, оказались весьма эффективными в обнаружении сложных уязвимостей браузеров. Например, ClusterFuzz работает на более чем 25 000 ядер и обнаружил более 29 000 уязвимостей в Chrome.
Статический анализ: Еще одной недавней попыткой в мире поиска уязвимостей в браузерах, где доминирует фаззинг, является SYS, первый "статический/символический" инструмент для поиска ошибок в коде браузера, где статический анализ может расширить огромную базу кода браузера, разбив ее на более мелкие фрагменты. В частности, SYS использует статические средства проверки для поиска потенциальных мест уязвимости, а затем использует расширяемое символьное выполнение для анализа этих мест. Таким образом, SYS - это отличное направление для будущей работы в области поиска ошибок в браузерах с помощью статического анализа.
Автоматизированный поиск уязвимостей - это здорово, но все еще нуждается в улучшении.
Самые продвинутые фаззеры в отрасли отлично справляются с обнаружением уязвимостей в браузере. Однако, как бы хороши они ни были, эти инструменты все равно не заменят ручной аудит, который по-прежнему является основным методом поиска сложных логических уязвимостей. В результате как в научных кругах, так и в промышленности необходимы более совершенные методы поиска уязвимостей.
Проактивные контрмеры
Большинство существующих мер по снижению уязвимости являются реактивными, то есть они применяются после обнаружения уязвимости, что недостаточно хорошо. Было бы идеально, если бы меры можно было принять до того, как произойдет атака (проактивный подход), что позволило бы победить неизвестные угрозы. Например, изоляция сайта изначально была разработана для борьбы с UXSS-атаками с использованием внепроцессных iframe, но она также помогла победить атаки Spectre/Meltdown, которые исследователи обнаружили уже после начала проекта изоляции сайта. Это хороший пример проактивного подхода к борьбе с неизвестными угрозами.
В игре по реагированию на эксплойты защитник никогда не сможет победить атакующего, потому что действия защитника прозрачны для атакующего. Поставщики могут изменить ситуацию, скрытно развернув новые контрмеры, например, в "песочнице" в инфраструктуре безопасного просмотра. Это также может помочь в обнаружении уязвимостей и исправлении ошибок путем сбора образцов, которые с высокой вероятностью могут быть вредоносными. Кроме того, производители могут попробовать более агрессивные контрмеры, которые могут повлиять на пользовательский опыт в таких средах. Например, если рандомизация StructureID развернута в песочнице безопасного просмотра перед выпуском бюллетеня, большинство JIT-уязвимостей, связанных с оригинальным языком fakeobj, будут обнаружены.
В заключении
В этой статье мы представили первый SoK по безопасности браузеров. Сначала мы предоставили единую модель для изучения дизайна безопасности четырех основных браузеров и представили 10-летнее продольное исследование уязвимостей браузеров для изучения тенденций. Затем мы представим основные типы уязвимостей и предложим современные контрмеры. Мы также подробно рассмотрим реальные полноцепочечные эксплойты уязвимостей на Pwn2Own 2020. Данная статья проливает свет на область безопасности браузеров и представляет некоторые ключевые моменты, которые могут просветить исследователей и производителей браузеров относительно будущего направления улучшения безопасности браузеров.
Защита конфиденциальности в браузере
Одним из наиболее тревожных элементов нарушения конфиденциальности при просмотре веб-страниц является IP-адрес пользователя. Поскольку веб-серверы могут легко собирать и хранить IP-адреса, они могут немедленно раскрыть географическое местоположение пользователя с мелкой детализацией, основанной на сетевом окружении (например, NAT). Браузер Tor решает эту проблему с помощью протокола Onion, который перенаправляет соединение пользователя, используя несколько случайных узлов в сети Tor, и каждый узел не может знать как идентификатор пользователя (IP), так и его местоположение. место назначения. Тем не менее, все еще возможно нарушить конфиденциальность, просматривая зашифрованные последовательности сетевых пакетов с помощью методов "отпечатков пальцев" веб-сайтов. Другой браузер, Brave, не позволяет веб-сайтам отслеживать пользователей, удаляя все рекламные объявления и рекламные трекеры, содержащиеся на сайте, но история просмотров пользователя все равно может быть скомпрометирована.
Плагины и расширения
Плагины и расширения - это небольшие программы, которые настраивают функциональность браузера, предоставляя различные возможности. Плагины, такие как Java и Flash, работают в контексте веб-страницы, а расширения присоединяют к браузеру дополнительные функции. Несмотря на свои преимущества, плагины являются основным источником нестабильности браузера. Плагины также делают "песочницу" процесса рендеринга непрактичной, поскольку плагины пишутся третьими лицами, а производители браузеров не контролируют их доступ к операционной системе. Кроме того, расширения обладают особыми привилегиями в браузере, что делает их привлекательными целями в глазах злоумышленников.
Плагины NPAPI. NPAPI позволяет производителям браузеров разрабатывать подключаемые модули с общим интерфейсом. Когда браузер посещает страницу с неизвестным типом содержимого, он ищет и загружает доступные плагины для делегирования обработки содержимого. В результате злоумышленник может запустить уязвимость, назначив веб-странице определенный тип содержимого, тем самым обманом заставив браузер загрузить конкретный плагин с уязвимостью. Атаки, использующие плагины NPAPI, распространены во всех браузерах и платформах, особенно на Java, Flash и PDF. Чтобы противостоять этому, браузеры отделяют процесс плагина от основного процесса браузера, т.е. смягчение плагина вне процесса. Однако плагины все еще были доступны для эксплуатации в браузере, и их винили в снижении производительности и сбоях браузера. В конце концов, все браузеры перестали поддерживать плагин NPAPI.
Сложность развертывания контрмер
Поставщикам браузеров трудно развернуть контрмеры по следующим причинам.
a. Совместимость: Код третьих лиц (например, плагины для браузеров) зависит от кода браузера, чтобы функционировать должным образом. При внедрении смягчающих мер для браузера может быть нарушен код сторонних разработчиков, который производитель браузера не контролирует. Например, при попытке внедрить блокировку Win32k в Windows для Pepper Plugin API (PPAPI) Chrome возникали проблемы стабильности при применении патчей на Windows 8.1 и ниже, которые команда Chrome не могла отследить, затрагивающие, в частности, Flash, PDFium и Widevine. плагины. В результате блокировка PPAPI Win32k включена только для Windows 10, но не для Windows 8/8.1, чтобы избежать проблем со стабильностью.
b. Производительность: Стоимость добавления мер по снижению безопасности высока. Чтобы уменьшить угрозы безопасности, производители браузеров иногда предпочитают обменять производительность на безопасность, и наоборот. Например, отключение SharedArrayBuffer (SAB) во всех современных браузерах в начале 2018 года в качестве контрмеры против атак Spectre, как обсуждалось в §IV-D, значительно ухудшило производительность, поскольку SAB изначально предназначался для обеспечения легкой синхронизации между рабочими .
c. Безопасность: Большее количество кода обычно означает больше уязвимостей в безопасности. Часто внедрение смягчений или исправлений увеличивает поверхность атаки. После развертывания нового патча для браузера производители браузеров часто ищут отчеты об уязвимостях, чтобы как можно скорее устранить новые проблемы безопасности. Например, Firefox ввел отдельную категорию вознаграждений за уязвимости в проактивных мерах противодействия.
d. Редуктивное смягчение: некоторые меры по смягчению применяются на разовой основе для борьбы с непосредственными угрозами, пока разрабатываются более эффективные меры по смягчению. Например, в случае с SAB, упомянутом выше, Chrome и Firefox снова включили SAB вскоре после внедрения более надежных контрмер (т.е. изоляции сайта и COOP/COEP). Несмотря на все усилия по обеспечению безопасности, высокой производительности и совместимости смягчений, иногда от смягчений приходилось отказываться из-за некоторых серьезных последствий, которые они влекли за собой. Например, в таблице IV, встроенный в Chrome XSS-фильтр XSS Auditor пострадал от многих побочных эффектов безопасности, что привело к его отказу от использования в 2019 году.
Оригинал находится здесь.
Веб-браузеры являются неотъемлемой частью повседневной жизни каждого человека. Они часто используются для обеспечения безопасности и конфиденциальности, как для банковских транзакций, так и для проверки медицинских записей. К сожалению, современные веб-браузеры настолько сложны, что неизбежно имеют уязвимости (например, 25 миллионов строк кода в Chrome), и роль их в киберпространстве делает их уязвимыми. Таким образом, веб-браузеры являются естественной ареной для демонстрации продвинутых методов использования злоумышленниками и современных средств защиты от поставщиков браузеров. Возможно, веб-браузеры — отличное место для изучения последних проблем и технологий безопасности, но из-за их быстро меняющейся природы и сложной кодовой базы веб-браузеры все еще не так хороши, как кажется большинству исследователей безопасности. Чтобы восполнить этот пробел, в этой статье систематически описывается среда безопасности современных веб-браузеров путем изучения популярных типов уязвимостей безопасности, методов их использования и развертывании средств защиты.
Во-первых, сначала мы представляем унифицированную архитектуру, демонстрирующую дизайн безопасности четырех основных веб-браузеров.
Во-вторых, мы делимся выводами из почти 10-летнего лонгитюдного исследования уязвимостей браузеров.
В-третьих, мы представляем график и контекст плана реагирования и его эффективности.
В-четвертых, мы делимся уроками, извлеченными из эксплойтов полной цепочки, использованных в соревновании Pwn2Own 2020 года. Мы считаем, что это систематическое "причесывание" ключевых моментов может показать, как улучшить текущее состояние современных веб-браузеров и, что более важно, как создавать безопасное и трудновзламываемое программное обеспечение в будущем. Веб-браузеры играют неотъемлемую роль в современном образе жизни, связанном с Интернетом. Мы полагаемся на веб-браузеры, чтобы оплачивать ипотечные кредиты, планировать прививки и общаться с людьми по всему миру. Другими словами, веб-браузеры становятся привратниками киберпространства, и их незащищенность представляет серьезную угрозу безопасности, справедливости и конфиденциальности нашего общества. К сожалению, веб-браузеры всегда были наиболее привлекательными и ценными целями для кибератак — в 2021 году [58] 50% 0-day уязвимостей будут атаками на веб-браузеры, угрожающими Интернету. Каждому человеку.
Таким образом, современные веб-браузеры, естественно, являются полем битвы для злоумышленников, желающих взломать систему с помощью новых эксплойтов, и поставщиков браузеров, стремящихся обеспечить безопасность пользователей с помощью самых современных контрмер. Поставщики браузеров действительно являются важными игроками в продвижении современных методов обеспечения безопасности благодаря:
- 1. Открытый исходный код не только текущей архитектуры и кода, но и самого процесса проектирования;
- 2. Ввести вознаграждение за обнаружение ошибок, чтобы поощрять обнаружение уязвимостей нулевого дня;
- 3. Заблаговременно обнаруживать уязвимости, которые можно использовать, путем разработки и запуска современных фаззеров в облаке.
В этой статье делается смелая попытка систематически разобраться в среде безопасности современных веб-браузеров.
Во-первых, мы предоставляем унифицированную модель для четырех основных веб-браузеров с точки зрения безопасности, а затем сравниваем и сопоставляем их решения в области безопасности, используя предоставленные модели.
Во-вторых, на основе этой модели мы анализируем уязвимости безопасности, обнаруженные в каждом браузере с открытым исходным кодом за последние 10 лет, и показываем, как они связаны с разработкой новых контрмер, программ вознаграждения за обнаружение ошибок и известных методов эксплойтов.
В-третьих, основываясь на наших исследованиях, мы делимся своими знаниями и извлеченными уроками, чтобы вдохновлять исследователей и разработчиков, формирующих будущее веб-браузеров. Мы надеемся, что такая попытка поможет им получить всестороннее представление о подходе каждого поставщика, тем самым улучшив их структуру безопасности, чтобы свести к минимуму влияние на безопасность и поверхность атаки.
Три уникальные характеристики затрудняют систематизацию знаний о безопасности веб-браузеров.
- 1. Темы постоянно меняются: поставщики браузеров очень быстро принимают решения (например, еженедельные обновления), и они развиваются намного быстрее, чем любое другое программное обеспечение, созданное людьми. Чтобы извлечь полезные уроки, мы стремимся сосредоточиться на фундаментальных проблемах проектирования и подходах в веб-браузерах.
- 2. Огромный объем исследований. Современные веб-браузеры состоят из миллионов строк кода, например, Chrome состоит из 25 миллионов строк кода. В дополнение к размеру проекта информация о веб-браузерах, такая как 0-day эксплойты и меры по смягчению последствий, разбросана по Интернету, не в состоянии предоставить целостную сводку и обзор ландшафта безопасности. В этой статье мы сосредоточим наши усилия на четырех основных веб-браузерах, а именно Chrome, Firefox, Safari и Edge, и изучим многочисленные общедоступные ресурсы для решения их проблем безопасности: средства отслеживания проблем отчеты CVE, кодовую базу и технические отчеты от поставщиков.
- 3. Отдельные спецификации: также важно обеспечить объективное представление о своих проблемах безопасности, каждый браузер имеет свои собственные спецификации и требования при принятии решений (например, сроки выпуска), фокусирование на фундаментальных проблемах имеет решающее значение. Чтобы решить эту проблему, мы предоставляем унифицированную архитектуру, которая может концептуально сравнивать и сопоставлять дизайн каждого браузера, не затрагивая детали их реализации.
Основное внимание в этом исследовании уделяется безопасности веб-браузера, включая защиту от собственных уязвимостей. Мы не рассматриваем другие проблемы безопасности, связанные с Интернетом, такие как проблемы безопасности веб-сайта или веб-сервера, такие как межсайтовый скриптинг (XSS), SQL-инъекция и т. д. Обратите внимание, что, хотя универсальный межсайтовый скриптинг (UXSS) звучит похоже на XSS, он часто возникает из-за проблем в реализации и дизайне браузеров и поэтому считается безопасностью веб-браузера (§III-E).
Архитектура современного браузера
В этом разделе представлена унифицированная модель для каждого веб-браузера, позволяющая объективно сравнивать их подходы.Современные веб-браузеры используют принцип наименьших привилегий и рассматривают процесс операционной системы как защищенный домен. Используя домены процессов, каждый веб-браузер можно описать тремя типами процессов, а именно БРАУЗЕРНЫЕ ПРОЦЕССЫ (обозначено зеленым), ПРОЦЕСС РЕНДЕРИНГА пурпурным, фактически в фиолетовой части изображения) и СПЕЦИФИНЫЕ ПРОЦЕССЫ (отмечены желтым цветом), как показано на рисунке ниже..
Внутренняя архитектура четырех основных браузеров.
Все браузеры развертывают песочницу (розовая область), чтобы ограничить средство визуализации, и подробный метод песочницы зависит от базовой ОС. Существуют тонкие, но важные различия между браузерами.
Браузерные процессы - при запуске веб-браузера процесс браузера запускается с тем же уровнем привилегий, что и пользователь (т. е. с более высокими привилегиями), и передает файл конфигурации песочницы в операционную систему, чтобы ограничить привилегии других процессов (т. е. с более низкими привилегиями). Он управляет всеми дочерними процессами (такими как средство визуализации) и является единственным процессом, который напрямую взаимодействует с пользователем через системные вызовы (и пользовательский интерфейс).
Процес рендеринга - этот процесс отвечает за синтаксический анализ и отображение ненадежного веб-контента. Постоянно увеличивающееся количество типов данных в Интернете привело к тому, что процессы рендеринга содержат широкий спектр компонентов, таких как синтаксические анализаторы мультимедиа, DOM и JS-движки. Поскольку они являются основным источником ошибок браузера, они ограничены изолированными программными средами (см. §II-C). Процессы визуализации обычно создаются для каждой вкладки браузера или веб-страницы. Политики изоляции для каждого средства визуализации различаются в зависимости от политик безопасности или возможностей каждого веб-браузера (например, изоляция сайта), ресурсов, доступных во время выполнения (например, нехватка памяти на мобильных устройствах) и даже конфигурации пользователя.
Другие процессы - Архитектура современных браузеров модульная. Модульный дизайн позволяет браузерам иметь разные уровни привилегий в зависимости от роли процесса. Службы, которые взаимодействуют с внешними драйверами (например, сетевые или графические процессы), выделяются как отдельные процессы, что обеспечивает более строгую песочницу для процессов, которым не требуется такой доступ (например, процессы рендеринга). Веб-браузеры также обычно размещают расширения и плагины в отдельных процессах. Это защищает плагины с более высокими уровнями привилегий от вредоносного веб-контента и защищает браузер от взлома в случае вредоносных плагинов.
Межпроцессное взаимодействие (IPC) - поскольку эти процессы не имеют прямого доступа к памяти друг друга, они всегда взаимодействуют через канал IPC, предоставляемый операционной системой, и связь обычно осуществляется через процесс браузера (прокси). Другими словами, процесс браузера действует как реляционный монитор, ограничивая прямой доступ к важным данным или привилегированным операциям (например, к файлам cookie или системным вызовам) из других процессов. Из-за этой многопроцессорной архитектуры атака всегда запускается из процесса с низким уровнем привилегий, такого как процесс рендеринга, и цель злоумышленника — взломать процесс браузера, работающий с привилегиями пользователя. В то же время он восстанавливается после сбоев, вызванных безобидными ошибками в процессе рендеринга, что делает браузер устойчивым к проблемам со стабильностью.
Same Origin Policy, в переводе с англ. — «Принцип одинакового источника» . На самом деле веб-сайты состоят из большого количества контента из разных источников, например, с использованием CDN для общих библиотек JavaScript, встраивания внешних сайтов через iframe или включения кнопок «Нравится» в социальных сетях. Сложность веб-сайтов способствовала многочисленным политикам безопасности и уникальным функциям каждого веб-браузера. В зависимости от происхождения каждого веб-сайта [94] процесс браузера и процесс рендеринга ограничивают ресурсы (например, файлы cookie), с которыми разрешено взаимодействовать веб-странице, что известно как политика единого происхождения (SOP)
Различия браузеров
Обсуждаемые до сих пор конструкции в равной степени применимы ко всем четырем основным браузерам. Однако, некоторые детали реализации будут различаться в зависимости от дизайна браузера и лежащей в его основе операционной системы. Например, процесс графического процессора в Chrome и Safari отделен от процесса рендеринга и использует профиль песочницы, чтобы позволить им получить доступ к платформе 3D API. Кроме того, в Chrome, Firefox и Safari есть отдельный процесс для веб-служб, в то время как веб-службы Chrome хранятся вне песочницы. В настоящее время команда Chrome внедряет песочницу для своих веб-сервисов. Песочница действительно защищает браузеры, однако с появлением атак Universal Cross-Site Scripting (UXSS) злоумышленники могут красть пользовательские данные из песочницы. Чтобы справиться с такими атаками, команда Chrome предложила изоляцию сайтов, чтобы еще больше разделить разные источники сайтов на разные процессы. Создается выделенный процесс для каждого источника сайта, поэтому нет неявного совместного использования между разными источниками сайтов. Изоляция сайта является эффективной мерой для решения проблемы UXSS, а также полезна для предотвращения аппаратных атак временного выполнения. У Firefox есть аналогичный проект под названием Fission, который был выпущен в Firefox_88_Beta.
JavaScript
Движок JavaScript лежит в основе современных браузеров, он преобразует код JavaScript в машинный код. Основные браузеры используют Just-In-Time (JIT) для ускорения выполнения кода. Кроме того, компилятор JIT моделирует результаты и побочные эффекты всех операций и запускает различные процессы анализа для оптимизации кода. Если какой-либо из них пойдет не так, будет сгенерирован и выполнен собственный код с проблемами повреждения памяти, что может привести к серьезным проблемам с безопасностью. Хотя каждый движок имеет различную реализацию, они используют схожие принципы проектирования и имеют общую поверхность атаки. Таким образом, злоумышленники могут создавать общие примитивы атаки для разных движков, такие как примитивы fakeobj и addrof и преобразование типов элементов. Механизмы JavaScript также используются вне браузера (например, Node.js использует V8), что усиливает влияние уязвимостей безопасности в механизмах JavaScript. Мы обсуждаем проблемы, вызванные браузерными движками того же типа, в §VI-A.
Рендеринг
Механизм рендеринга отвечает за интерпретацию ресурсов и рендеринг веб-страниц. Каждый из четырех больших браузеров имеет свой собственный движок рендеринга: Safari использует WebKit, Chrome использует Blink (производный от WebKit), Firefox использует Gecko, Edge использует Blink (заменяет EdgeHTML). Веб-стандарты служат базовыми спецификациями и ссылками для поставщиков браузеров при реализации своих механизмов рендеринга. По мере того, как веб-стандарты продолжают развивать новые функции, механизмы рендеринга также претерпевают быстрые изменения, т. е. внедряются новые функции или удаляются устаревшие функции. Из-за различных процессов принятия решений и стратегий реализации функции, реализованные в механизмах рендеринга разных браузеров, сильно различаются, и, следовательно, поверхность атаки также различна.
Различия в сценариях песочницы
Песочница ограничивает выполнение программы в случае, если она отклоняется от своего предназначения. Однако базовые технологии и архитектуры, используемые для создания сред песочницы, значительно различаются в разных операционных системах. Чтобы изучить внутреннюю структуру реализации песочницы, мы действуем следующим образом и суммируем наши выводы в таблице I.- Аудит исходного кода браузера.
- Мониторинг поведения API-интерфейса песочницы.
- Анализ предопределенных файлов политик песочницы (например, конфигурация браузера Safari).
Таблица I. Сравнение песочниц (Chrome, Firefox, Edge, Safari; в Windows, Linux, MacOS)
- Снижение разрешений с использованием системы разрешений таких платформ, как DAC/MAC, для применения более ограниченных разрешений к процессу песочницы;
- Разделение доменов, выделение отдельного ресурсного пространства для процесса песочницы;
- Уменьшите поверхность атаки, ограничив доступ к системным службам, ядру или драйверам устройств.
Мы также сравниваем возможности песочницы разных операционных систем (например, Windows, Linux и macOS).
- Windows: ограничение каждого процесса с помощью токена безопасности [117]. Как и в модели, основанной на возможностях, процесс, получивший определенный уровень токена, может получить доступ к привилегированным ресурсам с соответствующим уровнем дескриптора безопасности. Например, процесс рендерера выполняется на низком уровне маркера целостности, а прокси-процесс работает на среднем уровне маркера целостности, поэтому по умолчанию при переходе от процесса рендерера к прокси-процессу любой доступ на запись будет ограничен.
Однако единого протокола для детального управления доступом не существует. Чтобы решить эту проблему, Chrome и Firefox используют свои собственные механизмы IPC и исправления кода на двоичном уровне для функций, связанных с ресурсами, для поддержки мелких наборов правил [117]. Microsoft представила AppContainers в Windows 8, чтобы обеспечить более детальный контроль доступа к ресурсам, добавив функциональную концепцию «прикрепления к токену процесса». Edge создает песочницу на основе AppContainer [89]. Начиная с политики отказа по умолчанию, Edge создает набор возможностей для необходимых системных ресурсов. Chrome также экспериментирует с песочницами на основе AppContainer [28]. Браузеры также используют различные функции для работы с побегами из песочницы. Например, альтернативные рабочие столы и альтернативные оконные станции могут использоваться для противодействия атакам на основе пользовательского интерфейса, таким как Shatter [180]; «блокировка DACL по умолчанию» [24] и «произвольное ограничение SID» [38] были введены для обеспечения более строгого DACL, поэтому зараженный изолированный процесс не может получить доступ к другим изолированным процессам. - Linux: В отличие от Windows, песочницы Linux в основном основаны на seccomp, chroot и пространстве имен. Во-первых, seccomp — это стандартный фильтр системных вызовов, основанный на языке eBPF. Поскольку конфигурация seccomp по умолчанию слишком строгая, браузеры определяют свои собственные правила фильтрации. Например, Chrome применяет свои собственные правила seccomp ко всем процессам, кроме процесса брокера, и подробные правила различаются для каждого процесса. Во-вторых, для ограничения доступа к файлам браузерные песочницы на базе Linux используют chroot-тюрьму. После того, как процесс был ограничен с помощью chroot, нет возможности получить доступ к более высоким иерархиям файловой системы. Например, Firefox применяет chroot-тюрьму ко всем средствам визуализации и разрешает им доступ только к определенным файлам на основе файлового дескриптора, полученного от прокси-процесса. Кроме того, браузеры используют пространства имен [74] для создания отдельных пространств для различных ресурсов, таких как пользователь, сеть и IPC. Например, создание и объединение пространств имен пользователей позволяет изолированным процессам иметь отдельные идентификаторы UID и GID, эффективно отключая доступ к другим не изолированным процессам.
- macOS: в то время как Windows и Linux поддерживают различные типы примитивов песочницы, macOS поддерживает специально отформатированные файлы конфигурации песочницы (.sb) [75] для описания политики песочницы для данного процесса. Как правило, этот файл предоставляет список разрешенных абсолютных путей к файлам, к которым разрешен доступ, и по умолчанию блокирует доступ ко всем остальным файлам. Профиль также определяет возможность доступа к другим ресурсам, таким как сеть и общая память, и поддерживает фильтрацию на основе системных вызовов, такую как seccomp в Linux, хотя он развернут только в Safari.
Эксплуотация браузера
Целью эксплуатации браузера является кража конфиденциальных данных его пользователей или установка вредоносных программ для дальнейших действий. Злоумышленники могут выполнять такие атаки, как UXSS, чтобы напрямую украсть данные или выполнить код, а затем попытаться выйти из песочницы. Злоумышленники могут попытаться получить системные привилегии для выхода из песочницы, атакуя ядро, что выходит за рамки этой статьи. Благодаря различным обходным путям злоумышленнику необходимо связать вместе несколько ошибок (например, использовать 4 комбинации ошибок до выхода из песочницы, чтобы добиться произвольного выполнения. Даже после захвата потока управления, поскольку процесс рендеринга выполняется внутри песочницы, злоумышленнику необходимо найти еще один набор ошибок в прокси-процессе для выхода из песочницы. В зависимости от имеющихся в арсенале уязвимостей злоумышленники часто пытаются вырваться из «песочницы», используя ошибки в системных службах, драйверах или ядре, а не в прокси-процессах.
Уязвимости браузера и контрмеры
В этом разделе мы сначала проводим статистическое исследование общедоступных уязвимостей браузеров за последнее десятилетие, чтобы определить тенденции, а затем описываем основные типы уязвимостей (например, ошибки движка JavaScript) и соответствующие ответы, выпущенные их поставщиками.
Сценарии эксплуатации браузера и классификация уязвимостей
Тенденции уязвимости браузеров
Мы изучили общедоступные CVE и отчеты об уязвимостях для четырех основных браузеров:1. Регулярно обновляемые бюллетени безопасности от поставщиков браузеров .
2. Публичный трекер проблем, опубликованный вендором .
3. Репозитории с открытым исходным кодом имеют обычную практику отправки исправлений ошибок к опубликованным уязвимостям .
4. Отчеты CVE в Национальной базе данных уязвимостей (NVD) .
5. Эксплойты безопасности, используемые в реальном мире, такие как ошибка, используемая в Pwn2Own [61], и отчеты Google Project Zero.
Рисунок ниже показывает резкое увеличение числа уязвимостей безопасности во всех браузерах, особенно с 2010 года. Мы считаем, что это увеличение числа уязвимостей связано с растущим кодом браузера, поскольку постоянно добавляются новые функции. Кроме того, значительную роль сыграли достижения в методах поиска уязвимостей после 2010 года
Левая ось Y: количество уязвимостей в системе безопасности, правая ось Y: LoC двух браузеров с открытым исходным кодом (Firefox и Chromium) LoC основан на первом крупном обновлении версии каждый год. Примечание. LoC = строки кода.
Векторы динамических атак
Из-за огромного размера и постоянно меняющейся природы браузеров векторы атак постоянно меняются. Для браузеров с открытым исходным кодом Firefox и Chromium мы сопоставляем ошибки с соответствующими хост-компонентами и классами ошибок, как показано на рисунке 4. Для обоих браузеров мы использовали назначаемые разработчиком признаки для сопоставления ошибок с компонентами их основного браузера и описания уязвимостей с сопоставлением ключевых слов для их классификации.
Ошибки рендерера преобладают как в Firefox, так и в Chromium, потому что рендерер — это сердце браузера. Увеличение числа уязвимостей, связанных с спуфингом URL-адресов, в Chromium с 2016 года показывает, насколько легко найти уязвимости в ранее неисследованных областях. Ошибки памяти в целом и ошибки UAF в частности по-прежнему являются самой большой общей чертой обоих браузеров.
Еще один общий вывод заключается в том, что два браузера имели разное количество уязвимостей в двух областях на протяжении многих лет. Например, для компонентов с ошибками в Chromium в последнее время было больше эксплойтов DOM и HTML, но количество эксплойтов DOM и HTML в Firefox уменьшается. Что касается категории ошибок, большинство ошибок в Chromium в 2019 году были классифицированы как уязвимости UAF, OOB и спуфинга URL, но описание распространения ошибок в Firefox на протяжении многих лет было относительно одинаковым. Следовательно, эта разница не только интуитивно показывает изменяющиеся векторы атак, но и изменения в стратегиях классификации уязвимостей безопасности разных браузеров.
Сопоставление ошибок с компонентами браузера хоста и классами уязвимостей в Firefox и Chromium На этом рисунке показан годовой характер поверхности атаки браузера Цифры на каждом рисунке представлены в масштабе от минимума до максимума.
Усилия браузера по борьбе с ошибками также можно показать на графике. Изоляция сайта Chromium в ответ на уязвимость UXSS привела к значительному сокращению вышеуказанных уязвимостей после того, как в 2017 году была реализована изоляция сайта. Некоторые типы уязвимостей остаются основными источниками ошибок, например компоненты DOM и HTML
Уязвимости безопасности памяти являются критическими и доминирующими в браузерах. Например, Chromium помечает более 70% уязвимостей высокой степени серьезности как проблемы с безопасностью памяти, половина из которых — ошибки UAF. Как показано на рисунке, несмотря на контрмеры, в последнее десятилетие доминировали уязвимости безопасности памяти. Недавно были предприняты попытки переписать браузеры на безопасных для памяти языках, таких как Rust, чтобы уменьшить уязвимости, связанные с безопасностью памяти. Например, Mozilla переписывает части Firefox на Rust в рамках проекта под названием Oxidation. По состоянию на 2020 год проект Oxidation заменил 12% компонентов Firefox на Rust (написан эквивалентный модуль). Пять замененных подкомпонентов относятся к компоненту синтаксического анализа мультимедиа средства визуализации. Мы также отображаем количество дыр безопасности в памяти в компоненте анализа мультимедиа средства визуализации на рис ниже. Понятно, что с момента запуска Project Oxidation в 2015 году количество ошибок безопасности памяти в Firefox немного, но неуклонно снижается, при этом значительно меньше ошибок безопасности памяти в медиа-компоненте рендерера. Несмотря на многочисленные попытки производителей браузеров решить проблему безопасности памяти, ни одна из них не дала такого резкого эффекта, как Oxidation в Firefox.
Количество уязвимостей памяти и других уязвимостей в Firefox и других браузерах. RM-Mem — это количество уязвимостей безопасности памяти в компоненте парсинга мультимедиа средства визуализации Firefox, описывающее тенденцию к снижению с 2015 года после частичной перезаписи в Rust.
Использование языка, безопасного для памяти, может эффективно уменьшить уязвимости безопасности памяти.
Как показано на рисунке выше, использование Rust в Firefox эффективно для уменьшения уязвимостей безопасности памяти. Хотя это требует больших усилий, это фундаментальный подход, и именно он с наибольшей вероятностью устранит уязвимости безопасности памяти. Мы рекомендуем другим производителям браузеров следовать этой лучшей практике и постепенно переводить свои браузеры на безопасный для памяти язык.
Уязвимости браузеров
Уязвимости браузера при реальной атаке заслуживают большего внимания, поскольку с точки зрения злоумышленника они указывают на выявленный вектор атаки. Для изучения таких уязвимостей мы собираем информацию из надежных источников, которые получают только уязвимости с высокой степенью использования. Для эксплойтов, используемых в дикой природе, мы ссылаемся на регулярно обновляемый отчет Google Project Zero, в котором отслеживаются все общедоступные случаи эксплойтов нулевого дня с 2014 года. Мы также собирали эксплойты в Pwn2Own, реальном хакерском соревновании, спонсируемом Zero Day Initiative
Тенденции в отношении используемых компонентов браузера и категорий ошибок. Данные включают ошибки во всех браузерах. В строке указано совокупное количество ошибок. Ошибки движка JavaScript и UAF доминируют над используемыми компонентами ошибок и типами уязвимостей, соответственно.
Уязвимости парсера
Парсеры часто страдают от проблем с повреждением памяти, парсеры в браузерах не исключение. В веб-браузерах большинство уязвимостей синтаксических анализаторов возникает в синтаксических анализаторах мультимедиа или синтаксических анализаторах сетевых протоколов. Средство визуализации (медиа) занимает большую долю. Эти уязвимости легче использовать в процессе рендеринга, поскольку их можно использовать для повреждения объектов JS и создания более мощных примитивов эксплойта.После ужесточения распределителя кучи этот эксплойт стал более сложным или невозможным, в основном из-за разделения объектов JS в куче. Однако крупномасштабные фаззеры, такие как ClusterFuzz, также обнаружили много уязвимостей парсера. Поставщики браузеров работают над изолированием сетевого кода и переписыванием кода браузера на безопасных для памяти языках, таких как Rust. В результате таких уязвимостей становится меньше, и их сложнее использовать. Тем не менее, при анализе данных существуют зависимости от нескольких сторонних библиотек, поэтому обновления безопасности необходимо строго контролировать.
Уязвимости DOM
Уязвимости DOM являются популярной мишенью для злоумышленников; большинство эксплуатируемых уязвимостей были уязвимостями DOM. Поскольку большинство из них являются уязвимостями UAF, были развернуты контрмеры для снижения возможности их использования, такие как изоляция кучи и отложенный выпуск.Хотя фаззеры продолжают выявлять новые уязвимости DOM, из-за возросшей сложности эксплуатации уязвимостей DOM, недавно известные полноценные эксплойты в дикой природе, как правило, используются на деле уязвимости в других компонентах.
Контрмеры UAF эффективны в снижении эксплуатации уязвимостей DOM.
Поскольку ошибки DOM в значительной степени зависят от проблем UAF, они в основном решаются с помощью контрмер UAF. Обычные методы эксплуатации, основанные на обфускации типа указателя, стали невыполнимыми, поскольку куча разделяется по типам объектов, и нет общедоступной альтернативной техники. В результате, использование уязвимостей DOM больше не является предпочтительным методом взлома рендереров.
Ошибка движка JS
Среди недавних эксплойтов браузера эксплойты движка JS являются одной из самых популярных целей для эксплойтов браузера, особенно уязвимостей, связанных с оптимизацией. Не менее 34% эксплуатируемых уязвимостей используют эксплойты JS-движка для компрометации процесса рендеринга, что часто является первым шагом эксплойта с полной цепочкой браузера. Эксплойты движка JS можно использовать для создания мощных примитивов эксплойта, таких как addrof (оставление адреса любого объекта JS) и fakeobj (доступ к произвольному адресу как к объекту).Компилятор JIT в движке JS использует спекулятивную оптимизацию. Уязвимости в этих механизмах оптимизации являются более серьезными, чем традиционные уязвимости безопасности памяти (такие как повторное использование после освобождения или переполнение буфера), потому что они неустранимы, но предоставляют злоумышленникам мощные примитивы эксплойта. С точки зрения высокого уровня ошибки движка JS можно в основном разделить на четыре категории: - Уязвимости JIT-анализа: уязвимости в процессе анализа или модели JIT-компилятора. Такие уязвимости имеют наибольшую возможность использования и влияние. - Уязвимости мутации/генерации JIT-кода: уязвимости в процессе манипулирования графами JIT или генерации кода. - Ошибки побочных эффектов, не связанные с JIT: ошибки побочных эффектов во встроенных функциях JavaScript, в основном связанные с быстрым путем. - Уязвимости, не связанные с JIT Legacy, приводящие к повреждению памяти: другие уязвимости, приводящие к повреждению памяти, не подпадающие под указанные выше категории.
Мы изучили 45 эксплуатируемых уязвимостей; есть 13 уязвимостей JIT-анализа, 9 уязвимостей с побочными эффектами, не связанных с JIT, и 11 устаревших уязвимостей, связанных с повреждением памяти, но нет уязвимостей JIT-кода, связанных с изменением/генерацией кода. Мы подозреваем, что это связано с тем, что эту уязвимость сложно использовать. Большинство ошибок в JIT-компиляторах — это логические ошибки. Поскольку это инфраструктура компилятора, логические уязвимости могут быть преувеличены как дыры безопасности памяти в коде, скомпилированном JIT. Поэтому сложно сделать общие меры по устранению ошибок JIT.
Меры противодействия:
Примитивное исключение
Этот тип контрмер предназначен для предотвращения подделки злоумышленниками допустимых объектов с помощью примитива fakeobj. Например, в JavaScriptCore рандомизация StructureID использует 7 случайных битов энтропии для кодирования StructureID, что затрудняет угадывание злоумышленниками. Поскольку StructureID представляет тип и форму объекта JS, угадывание неправильного StructureID сделает форму недействительной, а доступ к ней в конечном итоге приведет к сбою процесса
Изоляция адресного пространства
Этот тип контрмер изолирует различные объекты, чтобы предотвратить их подделку или перезапись. GigaCage — это область виртуальной памяти объемом 4 ГБ, которая разделяет разные объекты на разные кучи (или виды кучи). Основная идея состоит в том, чтобы предотвратить доступ к памяти между разными кучами и использовать относительные смещения от базового адреса кучи для поиска объектов GigaCaged вместо абсолютных адресов. Таким образом, даже если указатель поврежден, он не может указывать ни на что за пределами исходной кучи. PACCage используется для защиты указателя буфера резервного хранилища TypedArray и использует код аутентификации указателя (PAC) поверх GigaCage для дальнейшего повышения безопасности. Песочница Chrome V8 Heap является экспериментальной и ее цель аналогична GigaCage, но она пытается защитить внешние указатели с помощью отдельной таблицы указателей, после чего злоумышленник не может создавать произвольные значения для внешних указателей.
Защита от перезаписи
Это стандартный механизм защиты, предотвращающий внедрение злоумышленниками произвольного исполняемого кода, и его можно рассматривать как последнюю линию защиты в контексте эксплойтов браузера.
- W ⊕ X — важный принцип безопасности, который обеспечивает, чтобы память была либо исполняемой, но недоступной для записи, либо доступной для записи, но не исполняемой. Этот ответ превосходит традиционные атаки с внедрением шелл-кода и обеспечивает основу для многих других методов защиты [62], [232]. Удивительно, но по соображениям производительности кодовые страницы JIT обычно не затрагиваются этим базовым смягчением и отображаются как rwx
- Выполнение только памяти - iOS 10 на устройствах ARMv8 получила аппаратную поддержку оперативной памяти (XOM), что позволяет JIT-компилированному коду включать секретные данные в качестве непосредственных значений. Safari использует XOM, чтобы скрыть адрес доступной для записи исполняемой карты от злоумышленника, введя функцию jit_memcpy только для выполнения, которая имеет внутренний базовый адрес карты JIT. Это делает произвольное чтение/запись недостаточным для перезаписи кодовой страницы JIT и вынуждает злоумышленника выбирать альтернативные пути, например перехватывать поток управления для вызова jit_memcpy.
- Быстрое переключение разрешений: APRR & MPK: внедрить аппаратную поддержку быстрого переключения разрешений, чтобы уменьшить нагрузку на переключение разрешений страниц с помощью mprotect(). Начиная с iOS 11 на устройствах ARMv8, APRR был развернут для включения разрешений для каждого потока путем сопоставления разрешений страницы (r, w, x) с восемью специальными регистрами, которые указывают фактические разрешения страницы потока. Точно так же Intel MPK добавляет одно 4-битное целое число на страницу для реализации двух дополнительных защит: запрет доступа и запрет записи. Таким образом, регион JIT всегда будет rx и разрешать запись только из выделенного потока копирования данных, изменяя разрешение на rw путем вызова функции разблокировки — только для целевого потока.
- Внепроцессорная JIT - в Windows такие средства защиты, как Arbitrary Code Guard (ACG), гарантируют, что процесс может отображать только подписанный код в свою память. Однако браузеры интенсивно используют компилятор JIT для повышения производительности, который генерирует неподписанный собственный код в процессе обработки содержимого. Внепроцессная JIT была введена для включения ACG с JIT-компилятором. Таким образом, функциональность JIT перемещена в отдельный процесс, который работает в своей собственной песочнице, отвечающей за компиляцию кода JS и его сопоставление с процессом. Поэтому процессу содержимого никогда не будет разрешено сопоставлять или изменять свою собственную кодовую страницу JIT.
- Устранение повторного использования кода на основе JIT - JIT Spray — это метод внедрения больших объемов контролируемого злоумышленником JIT-кода (помеченного как исполняемый) в предсказуемые адреса в памяти для обхода ASLR/DEP, аналогично Heap spray. Чтобы смягчить JIT-spray, браузеры накладывают ограничения на размер JIT-кода и переключаются на 64-разрядные платформы с высокой энтропией ASLR, что делает JIT-spray невозможным. Однако, если злоумышленник знает их адреса, гаджеты JIT-кода могут быть использованы. Эта атака называется атакой повторного использования кода на основе JIT (JCRA). Здесь мы кратко суммируем меры противодействия таким атака
и неразборчивые инструкции кадра вызова
Внутренняя рандомизация - Злоумышленник также может использовать относительное расположение инструкций друг к другу или предсказуемое смещение от базового адреса. Некоторые контрмеры, направленные на диверсификацию компоновки кода JIT, включают: рандомизацию относительных смещений между различными парами инструкций и случайную вставку свободного места перед первой кодовой единицей
Хотя проводятся эксперименты по предотвращению определенных типов уязвимостей (§IV-D), охватить их все сложно. Поэтому контрмеры в движках JS сосредоточены на устранении примитивов атаки. Недавно команда Edge добавила новую функцию безопасности под названием Super Duper Secure Mode (SDSM), которая фактически отключает JIT-компиляцию. Пользователи могут отключить JIT на менее посещаемых сайтах. Несмотря на некоторую потерю производительности, это отличный способ уменьшить поверхность атаки. Несмотря на то, что было введено несколько контрмер, JCRA по-прежнему полезен, поскольку поставщик не инвестировал много ресурсов для реализации или поддержания контрмер.
Бороться с уязвимостями JS-движков очень сложно. Уязвимости движка JavaScript, особенно уязвимости JIT-компилятора, являются очень мощными, поскольку злоумышленник может выпустить код с проблемами повреждения памяти. Поскольку бороться с логическими уязвимостями зачастую сложно, многие контрмеры направлены на предотвращение эскалации эксплойтов на языке оригинала. В результате поставщики часто внедряют меры по снижению риска, которые прерывают путь эксплойта, и постоянно совершенствуют их для предотвращения будущих атак.
Обход SOP и уязвимости UXSS
Политика единого источника (SOP) применяется веб-браузерами для поддержания границ безопасности между разными источниками. Уязвимости обхода SOP можно использовать для компрометации SOP в разной степени: от утечки одного бита до кражи целой страницы данных. Уязвимости UXSS — это самый мощный тип уязвимости обхода SOP, который можно использовать для облегчения междоменного выполнения кода JavaScript. При атаке UXSS злоумышленник может внедрить скрипты в любой затронутый контекст, используя уязвимости в веб-браузерах или сторонних расширениях для достижения той же цели, что и использование XSS на цели. Уязвимость веб-сайта имеет тот же эффект.Изоляция сайта — одна из наиболее важных контрмер против UXSS-атак. Изоляция сайта обеспечивает соблюдение SOP на уровне процесса, что делает невозможным использование большинства существующих уязвимостей UXSS. После постепенного применения изоляции сайтов после 2017 года количество зарегистрированных уязвимостей UXSS значительно уменьшилось, как показано на рисунке 6. Но уязвимости UXSS в сторонних расширениях все еще существуют; в популярных расширениях было обнаружено множество уязвимостей UXSS, которые позволяют злоумышленникам обходить изоляцию сайта и красть учетные данные пользователей. Изоляция сайта является эффективной мерой по снижению уязвимостей UXSS. Однако только Chrome и Firefox развернули изоляцию сайта, поскольку это требует значительных инженерных работ.
Дополнительные меры безопасности в браузерах
В этом разделе мы описываем более общие контрмеры, реализованные поставщиками браузеров, которые не были рассмотрены в предыдущих разделах. Мы провели лонгитюдное исследование ответов, реализованных в четырех основных браузерах за последнее десятилетие, вместе с датами их применения и прекращения использования
Песочница
Песочница имеет решающее значение для безопасности браузера, поскольку она ограничивает влияние уязвимостей в процессе рендеринга, который содержит различные компоненты, подверженные проблемам. За исключением случаев, подобных UXSS, злоумышленникам необходимо использовать уязвимости в ядре, системных службах или процессах браузера, чтобы выйти из песочницы рендерера. Таким образом, это значительно поднимает планку для атаки, поскольку злоумышленникам необходимо использовать оба компонента (рендерер и песочницу) для выполнения атаки 0-day по полной цепочке.
Блокировка Win32k - Поскольку большинство уязвимостей ядра Windows существует в системных вызовах Win32k, в 2012 году Microsoft ввела политику отключения системных вызовов — Win32k Lockdown для Windows. Разработчики Windows-приложений могут полностью блокировать доступ к таблице системных вызовов Win32k, значительно уменьшая поверхность атаки. Edge, Chrome и Firefox уже используют этот механизм для защиты браузера. Поэтому реализация выхода из песочницы из процесса визуализации становится более сложной.
Песочница на базе гипервизора - Application Guard в Защитнике Windows (WDAG) был представлен Microsoft для изоляции ненадежных веб-сайтов или ресурсов (например, файлов) в корпоративных сценариях. WDAG использует Hyper-V для создания нового экземпляра Windows на аппаратном уровне, который включает в себя отдельную копию ядра и минимальные службы платформы Windows, чтобы обеспечить правильную работу браузера Edge. WDAG реализован в Edge для предотвращения расширенных атак, которые могут обойти изолированную программную среду браузера. Благодаря WDAG злоумышленникам необходимо избегать песочниц и виртуальных машин Hyper-V.
Улучшенное распределение
По соображениям производительности и безопасности браузеры используют специализированные распределители кучи для многих объектов. Эти распределители используют особую конструкцию, помогающую снизить ущерб за счет ограничения примитивов атаки.
Изолированная куча: Изоляция кучи является эффективной защитой от атак UAF, которые перерастают в атаки обфускации типов. Изолируя объекты на основе:
1) типа;
2) уровня риска безопасности (например, встраивание указателей на v-таблицы);
3) доступности JavaScript (например, ArrayBuffer), изоляция кучи эффективно повышает порог эксплуатации уязвимости UAF. Изоляция не позволяет злоумышленнику повторно объявить освобожденный объект, используя объект с другим расположением, что является классической операцией в эксплойтах UAF браузера.
Современные браузеры реализуют базовый уровень разделения кучи между JavaScript-доступными объектами (JavaScript) и другими объектами. Однако все еще возможно вызвать путаницу типов между объектами в одной и той же куче, но других типов с помощью UAF. Чтобы предотвратить такие атаки, Safari и Firefox вводят отдельные кучи для каждого типа в данной категории, что обеспечивает более тонкую изоляцию. В результате, не существует общедоступного универсального эксплойта для эксплуатации уязвимостей UAF во всех браузерах.
Отложенное освобождение: Другая контрмера, отложенное освобождение, эффективно затрудняет использование уязвимостей UAF, но этот метод не ограничивает утилизацию висячих указателей. Браузеры используют различные алгоритмы сбора мусора (GC) для освобождения объектов без ссылок на куче; некоторые варианты алгоритма GC дополнительно сканируют стек и кучу на предмет ссылок, которые могли быть пропущены, что известно как консервативное сканирование или отложенное освобождение. Примечательно, что Firefox отказался от этой стратегии в пользу точного укоренения и написал инструмент статического анализа для поиска небезопасного использования ссылок в стеке. Chrome имеет аналогичный инструмент, но он применяется только в определенных регионах. Однако отложенный выпуск вводит примитивы побочных каналов, которые могут быть использованы для поражения механизма ASLR, поскольку он не может отличить указатели на кучу от целых чисел, управляемых пользователем.
Защита метаданных кучи: Защита метаданных кучи - это метод проверки части метаданных блока кучи для предотвращения повреждения кучи и распространения тихих уязвимостей в куче. Например, распределитель кучи может поместить случайное значение перед опасной структурой данных для обнаружения уязвимостей кучи, а PartitionAlloc в Chrome удаляет встроенные метаданные и помещает страницу защиты, чтобы предотвратить линейные переполнения кучи от перезаписи метаданных. Существуют также некоторые усилия по защите метаданных на уровне ОС.
Другие средства защиты кучи: Отравление фреймов в Firefox освобождает блоки памяти, адреса которых указывают на недоступные страницы памяти. Аналогично, в Edge это делается путем заполнения блока кучи нулями при его освобождении. GWP-ASan в Chrome размещает небольшую случайную часть выделенных объектов до/после защиты страницы и освобождает всю страницу при освобождении блока для обнаружения ошибок кучи в естественных условиях.
Целостность потока управления
Поскольку злоумышленники часто манипулируют значениями указателей команд для достижения выполнения кода, целостность потока управления обеспечивается для предотвращения перехвата потока управления, что затрудняет атаки. Инфраструктура компилятора, операционная система и аппаратная поддержка обеспечивают большинство смягчений в этой категории, таких как защита таблиц виртуальных функций путем введения канареечных значений и разрешение перечисления косвенных ветвей путем проверки целевого адреса.
Ведется работа по предотвращению произвольной записи в память для модификации областей кода, которые могут быть выполнены злоумышленником. На основе аппаратной поддержки браузеры могут применять дополнительные контрмеры без существенного снижения производительности, например, добавление проверок целостности указателей с помощью PAC на ARM64, дополнительная защита W ⊕ X и APRR для JIT-компилированного кода с помощью Intel MPK.
Сторонние (боковые) каналы
Браузеры также уязвимы для атак по боковым каналам. Исследования на сегодняшний день показали, что конфиденциальная информация в браузерах может быть получена из:
1. состояния микроархитектуры
2. графических процессоров;
3. каналов синхронизации с плавающей запятой;
4. каналов измерения, специфичных для браузера
Исследователи представили защитные механизмы] для защиты браузеров от атак по боковым каналам, такие как DeterFox и FuzzyFox . Кроме того, производители браузеров внедрили средства защиты, которые делятся на следующие две категории.
Уменьшение разрешения таймера: поскольку большинство атак опирается на точное определение времени, чтобы затруднить обнаружение небольших временных различий, производители браузеров уменьшили разрешение точных таймеров (например, performance.now()) и ввели случайный джиттер для предотвращения восстановления разрешения. После обнаружения Spectre и Meltdown производитель еще больше снизил точность таймера. Поскольку SharedArrayBuffer мог использоваться для создания таймеров высокого разрешения, SharedArrayBuffer был отключен во всех современных браузерах вскоре после обнаружения Spectre.
Предотвращение совместного использования ресурсов: Еще одна техника противодействия заключается в предотвращении совместного использования ресурсов жертвой и злоумышленником. Изоляция сайта эффективно справляется с переходным выполнением на основе Javascript. Политики Cross-Origin-Opener-Policy (COOP) и Cross-Origin-Embedder-Policy (COEP) были введены для создания среды междоменной изоляции. COOP позволяет веб-сайтам включать заголовки ответов в документы верхнего уровня, гарантируя, что междоменные документы не имеют общего просмотра. COEP предотвращает загрузку страницей любого междоменного ресурса, который не был явно разрешен этой странице. Они обеспечиваются с помощью HTTP-заголовков и доступны в Chrome 83, Firefox 79 и Edge 83, в то время как по состоянию на ноябрь 2021 года Safari их не поддерживает.
Использование SharedArrayBuffer было вновь включено в Chrome и Firefox после внедрения изоляции сайтов и COOP/COEP. Однако одно исследование показало, что повторное введение SharedArrayBuffer увеличило пропускную способность скрытого канала в 2 000 и 800 000 раз соответственно. Две недавние работы показывают, что, несмотря на изоляцию сайтов в Chrome, злоумышленники все равно могут получить доступ к конфиденциальной информации в разных доменах.
Другие контрмеры
Смягчение UAF: Для устранения основной причины проблем UAF, не покрываемых сбором мусора или другими мерами безопасности, команда Chrome ввела термин MiraclePtr, который обозначает набор алгоритмов, позволяющих обернуть необработанные указатели в C/C++ так, чтобы их нельзя было использовать через UAF. Ожидается, что MiraclePtr вскоре Ожидается, что MiraclePtr будет введен в использование в ближайшее время.
Улучшение безопасности памяти: команда Chrome изучила усовершенствования в кодовой базе C++, которые могут устранить или уменьшить конкретные типы уязвимостей путем ограничения использования специфичных для языка функций (например, исключений C++ ) и внедрения классов-оберток вокруг целочисленных операций.
Улучшение JIT-компилятора: Было предпринято много усилий для защиты от опасных операций оптимизации в JIT-компиляторе. Например, во многих эксплойтах для устранения "кажущихся излишними" проверок границ используется метод bounds check elimination. Чтобы решить эту проблему, команда Chrome ввела исправление, которое помечает такие проверки как "прерывание", а не просто удаляет их. Кроме того, чтобы сделать генерацию байткода стандартных функций JS менее подверженной ошибкам, команда Chrome разработала специфический для данной области язык Torque, который заменяет существующую реализацию C++ и уменьшает количество LoCs.
Совместные усилия по реагированию могут принести пользу.
Когда один поставщик внедряет контрмеру, другие могут последовать его примеру. В таблице IV мы видим, что многочисленные контрмеры были приняты несколькими браузерами. Если уязвимость обнаружена в одном браузере, производитель может быстро поделиться информацией с другими производителями и вместе они могут использовать свои коллективные знания для создания лучшего обходного пути. В случае с атакой Spectre/Meltdown хорошим примером совместных усилий является совместная работа производителей браузеров над разработкой плана по снижению непосредственной угрозы.
Тематическое исследование: Эксплуатация всей цепи
Поскольку современные браузеры имеют различные функции безопасности, браузерные эксплойты часто требуют соединения нескольких атак, чтобы в конечном итоге выполнить вредоносное действие. Объединение всех этих этапов часто называют полноцепочечной эксплуатацией. В качестве показательного примера эксплуатации браузера с полной цепочкой мы проанализировали успешную атаку на Safari в соревновании Pwn2Own 2020 года.
Эта атака проникла в процесс рендеринга, начавшись с уязвимости оптимизации JIT-компилятора: компилятор DFG в Safari JavaScript renderer неправильно моделирует побочные эффекты оператора "in", когда выполняется специальное условие для прокси-объектов. Эта уязвимость позволяет злоумышленнику сконструировать стандартный примитив addrof/fakeobj для произвольного чтения/записи памяти и, в конечном итоге, выполнения произвольного кода. Для того, чтобы создать действительный объект с помощью fakeobj, злоумышленники используют хорошо известную технику обхода аутентификации формы объекта (рандомизация идентификатора структуры ). После подделки объекта JavaScript они используют известную технику для обхода изоляции адресного пространства (Gigacage) и получения произвольных примитивов чтения/записи в процессе рендеринга.
Если процесс рендеринга скомпрометирован, следующим шагом будет побег из песочницы, что гораздо сложнее. В этой атаке злоумышленник ловко соединил несколько логических/памятных эксплойтов, чтобы избежать "песочницы". Сначала злоумышленник дополнительно получает выполнение произвольного кода от службы CVMServer XPC (часть встроенного фреймворка OpenGL), которая находится в песочнице, но имеет возможность создавать символические ссылки, чего нет у процесса рендеринга. Кроме того, Safari имеет IPC-метод didFailProvisionalLoad(), который может запускать произвольные приложения, если предоставлена символическая ссылка на папку приложения. Объединив их, злоумышленник может запустить любое приложение через Safari. В этот момент песочница успешно нарушена, поскольку они могут выполнять произвольные приложения за пределами песочницы рендерера, подобно пользователю, запустившему Safari.
Наше резюме примера Pwn2Own является конкретным, но действенным. Исходя из этого, мы описываем эксплойт для браузера с полной цепочкой в более общем виде. Во-первых, для поиска уязвимостей в рендере можно использовать методы fuzz-тестирования или вручную просмотреть исходный код браузера. Поиск эксплуатируемых ошибок будет одним из самых сложных этапов. После обнаружения таких уязвимостей следующим шагом является реализация примитивов выполнения произвольного кода в контексте процесса рендеринга. Однако получение контроля над рендерером - это только начало, поскольку рендерер ограничен механизмом "песочницы". Чтобы прорваться через "песочницу", злоумышленники обычно нацеливаются на дефекты в процессе браузера, ядре операционной системы или протоколе IPC. В отличие от атаки на рендерер, для побега из песочницы обычно требуется связать уязвимости логики высокого уровня с несколькими компонентами системы. После выхода из "песочницы" злоумышленник может выполнить произвольную программу с тем же уровнем безопасности, что и браузер, что позволяет осуществить атаку по всей цепочке.
Обсуждение
В этом разделе мы обсудим несколько аспектов, связанных с безопасностью браузера.
Проблемы в патчах
Благодаря существованию публичных репозиториев и трекеров проблем, исправления в браузерах с открытым исходным кодом могут быть сначала выложены в открытый доступ, до того как новые версии будут завершены и выпущены для конечных пользователей, что позволяет злоумышленникам оценить возможность использования исправлений. Например, iOS Safari эксплуатировался из-за полуторамесячного отсутствия патча. Чтобы устранить этот пробел, Chrome ввел обновления безопасности раз в две недели и сократил цикл выпуска с шести до четырех недель. Firefox не позволяет размещать исправления безопасности в хранилище до их выпуска и рекомендует не включать информацию об уязвимостях в заявки на исправления.
Однородность браузерных движков
Многие "вторичные браузеры" используют тот же браузерный движок, что и ведущий браузер (например, Chrome V8). В результате уязвимости в одном движке браузера могут повлиять на другие браузеры с общим движком. Из 15 самых популярных браузеров 11 основаны на движке Chrome (включая Microsoft Edge ). Когда выходит новая версия Chrome с исправлениями ошибок, они не сразу применяются во вторичных браузерах; существует временной лаг, прежде чем вторичные браузеры интегрируют их.
В зависимости от истории выпуска суббраузера, существует временной лаг до применения выпущенных исправлений безопасности, что обеспечивает окно атаки для злоумышленников. Например, уязвимость WebKit может быть использована на прошивке PlayStation через несколько месяцев после того, как о ней было сообщено в системе отслеживания ошибок WebKit. Это также является проблемой в Android, где приложения поставляются с встроенными движками рендеринга, например, об уязвимости UXSS было сообщено в интернет-браузере Samsung Internet (Samsung Internet) примерно через месяц после сообщения о ней в Chromium. Apple смогла использовать эту уязвимость, заставив все приложения использовать библиотеку WebKit, предоставляемую ОС, и запретив использование библиотеки WebKit. несоответствующие приложения в своем App Store, чтобы решить эту проблему в iOS.
Кроме того, использование компонентов веб-браузера, таких как рендереры и движки JavaScript, распространяется и на приложения, использующие такие фреймворки, как Electron и Android WebView. Кроме того, Node.js и Deno используют движок V8 от Google для включения JavaScript вне контекста браузера (например, для реализации веб-сервера). В результате уязвимости и эксплойты в движке браузера влияют не только на сам браузер, но и на необходимость создания более совершенных защитных механизмов для предотвращения катастрофических последствий.
Однородность движков браузеров вызывает серьезные проблемы; необходимы более совершенные исправления Из-за однородности браузерных движков уязвимости в одном браузерном движке могут повлиять на многие другие браузеры и приложения. Мы рекомендуем ведущим браузерам (например, Chrome) сделать свои движки JavaScript доступными для других приложений в виде общих библиотек, чтобы исправления было легче развертывать через обновления по сети, а не вручную интегрированные исправления.
Средства обнаружения уязвимостей
Было приложено много усилий для разработки современных инструментов для обнаружения ошибок в браузерных движках, и эти инструменты можно разделить на две основные категории: fuzzing и статический анализ.
Фаззинг - одна из самых эффективных стратегий поиска ошибок, которая используется для поиска ошибок в браузерах с 2012 года. Safari и Edge (на базе ChakraCore и V8), а также их ключевые приемы. Эти фаззеры выбирают между двумя классическими моделями: мутационный фаззинг (например, Montage ) и генерационный фаззинг (например, CodeAlchemist ). Некоторые фаззеры, такие как Lang-Fuzz и DIE, используют смесь этих двух моделей, а также обратную связь по покрытию. Создание синтаксически и семантически осведомленных входов, таких как DIE и LangFuzz, полезно для генерации большего количества сбоев. Некоторые усилия, направленные на промышленную природу нечетких браузеров, оказались весьма эффективными в обнаружении сложных уязвимостей браузеров. Например, ClusterFuzz работает на более чем 25 000 ядер и обнаружил более 29 000 уязвимостей в Chrome.
Статический анализ: Еще одной недавней попыткой в мире поиска уязвимостей в браузерах, где доминирует фаззинг, является SYS, первый "статический/символический" инструмент для поиска ошибок в коде браузера, где статический анализ может расширить огромную базу кода браузера, разбив ее на более мелкие фрагменты. В частности, SYS использует статические средства проверки для поиска потенциальных мест уязвимости, а затем использует расширяемое символьное выполнение для анализа этих мест. Таким образом, SYS - это отличное направление для будущей работы в области поиска ошибок в браузерах с помощью статического анализа.
Автоматизированный поиск уязвимостей - это здорово, но все еще нуждается в улучшении.
Самые продвинутые фаззеры в отрасли отлично справляются с обнаружением уязвимостей в браузере. Однако, как бы хороши они ни были, эти инструменты все равно не заменят ручной аудит, который по-прежнему является основным методом поиска сложных логических уязвимостей. В результате как в научных кругах, так и в промышленности необходимы более совершенные методы поиска уязвимостей.
Проактивные контрмеры
Большинство существующих мер по снижению уязвимости являются реактивными, то есть они применяются после обнаружения уязвимости, что недостаточно хорошо. Было бы идеально, если бы меры можно было принять до того, как произойдет атака (проактивный подход), что позволило бы победить неизвестные угрозы. Например, изоляция сайта изначально была разработана для борьбы с UXSS-атаками с использованием внепроцессных iframe, но она также помогла победить атаки Spectre/Meltdown, которые исследователи обнаружили уже после начала проекта изоляции сайта. Это хороший пример проактивного подхода к борьбе с неизвестными угрозами.
В игре по реагированию на эксплойты защитник никогда не сможет победить атакующего, потому что действия защитника прозрачны для атакующего. Поставщики могут изменить ситуацию, скрытно развернув новые контрмеры, например, в "песочнице" в инфраструктуре безопасного просмотра. Это также может помочь в обнаружении уязвимостей и исправлении ошибок путем сбора образцов, которые с высокой вероятностью могут быть вредоносными. Кроме того, производители могут попробовать более агрессивные контрмеры, которые могут повлиять на пользовательский опыт в таких средах. Например, если рандомизация StructureID развернута в песочнице безопасного просмотра перед выпуском бюллетеня, большинство JIT-уязвимостей, связанных с оригинальным языком fakeobj, будут обнаружены.
В заключении
В этой статье мы представили первый SoK по безопасности браузеров. Сначала мы предоставили единую модель для изучения дизайна безопасности четырех основных браузеров и представили 10-летнее продольное исследование уязвимостей браузеров для изучения тенденций. Затем мы представим основные типы уязвимостей и предложим современные контрмеры. Мы также подробно рассмотрим реальные полноцепочечные эксплойты уязвимостей на Pwn2Own 2020. Данная статья проливает свет на область безопасности браузеров и представляет некоторые ключевые моменты, которые могут просветить исследователей и производителей браузеров относительно будущего направления улучшения безопасности браузеров.
Защита конфиденциальности в браузере
Одним из наиболее тревожных элементов нарушения конфиденциальности при просмотре веб-страниц является IP-адрес пользователя. Поскольку веб-серверы могут легко собирать и хранить IP-адреса, они могут немедленно раскрыть географическое местоположение пользователя с мелкой детализацией, основанной на сетевом окружении (например, NAT). Браузер Tor решает эту проблему с помощью протокола Onion, который перенаправляет соединение пользователя, используя несколько случайных узлов в сети Tor, и каждый узел не может знать как идентификатор пользователя (IP), так и его местоположение. место назначения. Тем не менее, все еще возможно нарушить конфиденциальность, просматривая зашифрованные последовательности сетевых пакетов с помощью методов "отпечатков пальцев" веб-сайтов. Другой браузер, Brave, не позволяет веб-сайтам отслеживать пользователей, удаляя все рекламные объявления и рекламные трекеры, содержащиеся на сайте, но история просмотров пользователя все равно может быть скомпрометирована.
Плагины и расширения
Плагины и расширения - это небольшие программы, которые настраивают функциональность браузера, предоставляя различные возможности. Плагины, такие как Java и Flash, работают в контексте веб-страницы, а расширения присоединяют к браузеру дополнительные функции. Несмотря на свои преимущества, плагины являются основным источником нестабильности браузера. Плагины также делают "песочницу" процесса рендеринга непрактичной, поскольку плагины пишутся третьими лицами, а производители браузеров не контролируют их доступ к операционной системе. Кроме того, расширения обладают особыми привилегиями в браузере, что делает их привлекательными целями в глазах злоумышленников.
Плагины NPAPI. NPAPI позволяет производителям браузеров разрабатывать подключаемые модули с общим интерфейсом. Когда браузер посещает страницу с неизвестным типом содержимого, он ищет и загружает доступные плагины для делегирования обработки содержимого. В результате злоумышленник может запустить уязвимость, назначив веб-странице определенный тип содержимого, тем самым обманом заставив браузер загрузить конкретный плагин с уязвимостью. Атаки, использующие плагины NPAPI, распространены во всех браузерах и платформах, особенно на Java, Flash и PDF. Чтобы противостоять этому, браузеры отделяют процесс плагина от основного процесса браузера, т.е. смягчение плагина вне процесса. Однако плагины все еще были доступны для эксплуатации в браузере, и их винили в снижении производительности и сбоях браузера. В конце концов, все браузеры перестали поддерживать плагин NPAPI.
Сложность развертывания контрмер
Поставщикам браузеров трудно развернуть контрмеры по следующим причинам.
a. Совместимость: Код третьих лиц (например, плагины для браузеров) зависит от кода браузера, чтобы функционировать должным образом. При внедрении смягчающих мер для браузера может быть нарушен код сторонних разработчиков, который производитель браузера не контролирует. Например, при попытке внедрить блокировку Win32k в Windows для Pepper Plugin API (PPAPI) Chrome возникали проблемы стабильности при применении патчей на Windows 8.1 и ниже, которые команда Chrome не могла отследить, затрагивающие, в частности, Flash, PDFium и Widevine. плагины. В результате блокировка PPAPI Win32k включена только для Windows 10, но не для Windows 8/8.1, чтобы избежать проблем со стабильностью.
b. Производительность: Стоимость добавления мер по снижению безопасности высока. Чтобы уменьшить угрозы безопасности, производители браузеров иногда предпочитают обменять производительность на безопасность, и наоборот. Например, отключение SharedArrayBuffer (SAB) во всех современных браузерах в начале 2018 года в качестве контрмеры против атак Spectre, как обсуждалось в §IV-D, значительно ухудшило производительность, поскольку SAB изначально предназначался для обеспечения легкой синхронизации между рабочими .
c. Безопасность: Большее количество кода обычно означает больше уязвимостей в безопасности. Часто внедрение смягчений или исправлений увеличивает поверхность атаки. После развертывания нового патча для браузера производители браузеров часто ищут отчеты об уязвимостях, чтобы как можно скорее устранить новые проблемы безопасности. Например, Firefox ввел отдельную категорию вознаграждений за уязвимости в проактивных мерах противодействия.
d. Редуктивное смягчение: некоторые меры по смягчению применяются на разовой основе для борьбы с непосредственными угрозами, пока разрабатываются более эффективные меры по смягчению. Например, в случае с SAB, упомянутом выше, Chrome и Firefox снова включили SAB вскоре после внедрения более надежных контрмер (т.е. изоляции сайта и COOP/COEP). Несмотря на все усилия по обеспечению безопасности, высокой производительности и совместимости смягчений, иногда от смягчений приходилось отказываться из-за некоторых серьезных последствий, которые они влекли за собой. Например, в таблице IV, встроенный в Chrome XSS-фильтр XSS Auditor пострадал от многих побочных эффектов безопасности, что привело к его отказу от использования в 2019 году.
Оригинал находится здесь.