Эта статья — перевод оригинальной статьи Johnathan Norman "Super Duper Secure Mode"

Также я веду телеграм канал “Frontend по-флотски”, где рассказываю про интересные вещи из мира разработки интерфейсов.

Вступление

Команда VR (Vulnerability Research) экспериментирует с новой функцией, которая бросает вызов некоторым общепринятым предположениям, которых придерживаются многие в коммюнити браузеров. Мы надеемся создать что-то, что изменит современные эксплойты и значительно повысит трудозатраты для злоумышленников. Меры по смягчению последствий издавна обходятся без внимания, поэтому мы стремимся получить отзывы от сообщества, чтобы создать что-то ценное и долговременное.

Самое главное, что мы планируем получать - удовольствие от этого проекта. Это включает в себя присвоение эксперименту немного провокационного названия, так как мы думаем, что оно забавное, и еще слишком рано для чего-то официального.

Безопасность против производительности: пересмотр компромиссов

В этой команде мы довольно часто переключаемся между атакующими и оборонительными ролями. При работе с эксплойтами браузера нашей любимой целью всегда является V8. Ошибки движка JavaScript являются опорой для злоумышленников по разным причинам; они предоставляют мощные примитивы эксплойтов, есть постоянный поток ошибок, и эксплуатация этих ошибок часто осуществляется по простому шаблону. Эксплуатация движка JavaScript за последние годы практически не изменилась и в целом следует той же схеме:

Подделать объект
Получить AddrOf Primitive
Добиться "arbitrary write"

Мы можем эффективно скопировать/вставить наш баг в html-шаблон, что будет работать довольно быстро. У злоумышленников даже есть такие фреймворки, как PwnJS, которые позволяют быстрое преобразование.

Однако для стороны защиты это кошмар. Регулярный поток ошибок требует частых обновлений безопасности, а простота использования означает, что злоумышленники могут быстро использовать эксплойты, что полезно при злоупотреблении patch gap. Эта проблема характерна не только для V8, это обычная проблема для большинства современных движков JavaScript. Google, Mozilla, Microsoft и другие пытаются снизить этот риск, вкладывая большие средства в статический анализ, поощрение ошибок и фаззинг. Все это позволяет быстро выявить некоторые из этих проблем, но неизбежно некоторые из них упускаются. Механизмы JavaScript остаются чрезвычайно сложной проблемой безопасности для браузеров.

Почему? Что ж, проблема частично связана с технологией производительности под названием «Just-In-Time Compilation» (JIT). JIT были введены в браузеры в 2008 году для ускорения выполнения определенных задач в JavaScript. Механизмы с поддержкой JIT эффективно берут слабо типизированный JavaScript и компилируют его в машинный код непосредственно перед тем, как он понадобится. Этот процесс иногда называют «спекулятивной оптимизацией». Код JavaScript оптимизируется с помощью ряда сложных конвейеров обработки. Эти изменения приводят к впечатляющему приросту производительности. Разработчикам удалось сделать производительность JavaScript сопоставимой с C++, что является впечатляющим достижением. Однако в этот процесс входит очень многое. Чтобы обеспечить некоторую перспективу, вот общий обзор презентации V8, подготовленной Google в 2016 году.

Приведенная выше диаграмма - это лишь одна фаза всего конвейера обработки V8. Сюда не входят парсеры, интерпретатор, недавно добавленный второй JIT под названием Sparkplug или многие другие компоненты. Это чрезвычайно сложный процесс, который понимают очень немногие, и у него есть небольшая вероятность оши��ки.

За производительность и сложность часто приходится платить, и часто мы несем эту цену в виде ошибок безопасности и последующих исправлений. Анализ данных CVE (Common Vulnerabilities and Exposures) после 2019 года показывает, что примерно 45% CVE, выпущенных для V8, были связаны с механизмом JIT. Более того, мы знаем, что злоумышленники также используют эти ошибки в качестве оружия и злоупотребляют ими; Анализ, проведенный Mozilla, показывает, что более половины «обычных» эксплойтов Chrome злоупотребляли ошибкой JIT, как показано на диаграммах ниже. Примечание. «Edge» ниже относится к устаревшей версии Edge.

Стоит ли этого JIT?

Традиционно разработчики браузеров готовы принять эту плату, потому что пользователи хотят, чтобы их браузеры были «быстрыми», но что, если мы просто отключим JIT? Такое сокращение поверхности атаки может значительно повысить безопасность пользователей; он удалит примерно половину ошибок V8, которые необходимо исправить. Для пользователей это означает менее частые обновления безопасности и меньшее количество требуемых аварийных исправлений. Эти обновления и исправления часто вызывают разочарование у наших клиентов, особенно тех, кто работает в крупных корпоративных средах, которым необходимо тестировать обновления перед их развертыванием.

Есть преимущества, выходящие за рамки простого уменьшения вариантов атаки. Из-за того, как работает V8 JIT, несколько эффективных технологий смягчения последствий не могут быть задействованы в процессе рендеринга. Например, была отключена технология Controlflow-Enforcement Technology (CET), новая аппаратная защита от эксплойтов от Intel. Точно так же Arbitrary Code Guard (ACG) не был включен из-за использования страниц памяти RWX в процессе. Это прискорбно, потому что процесс рендеринга обрабатывает ненадежный контент хотя должен быть максимально заблокирован. Отключив JIT, мы можем затруднить использование ошибок безопасности в любом компоненте процесса рендеринга. Мэтт Миллер из Microsoft изложил эту стратегию в начале 2017 года.

Такое сокращение способов атаки устраняет половину ошибок, которые мы видим в эксплойтах, и каждую следующую ошибку становится труднее использовать злоумышленникам. Другими словами, мы снижаем затраты для пользователей, но увеличиваем затраты для злоумышленников.

Но как насчет производительности?

Производительность важна для команды Edge, и мы очень гордимся внесенными нами улучшениями. Это сложная тема, которая включает в себя широкий спектр вопросов, включая время запуска, потребление памяти, время рендеринга и многое другое. JavaScript играет ключевую роль в истории любого браузера. JIT существуют не просто так, а именно для оптимизации производительности JavaScript.

Мы посмотрели на результаты отключения JIT в нашей лаборатории. Лаборатория производительности Edge проводит сотни тестов, имитирующих реальные сайты и условия, чтобы оценить влияние изменений. Мы группируем эти тесты по таким категориям, как мощность, запуск, память и загрузка страницы. Во-первых, давайте посмотрим, какое количество тестов показали улучшение, регресс или отсутствие изменений.

Мы видим, что большинство тестов не показывают изменений при отключенном JIT. Есть несколько улучшений и регрессов, но большинство тестов осталось без изменений. Как ни странно, мы обнаружили, что пользователи с отключенным JIT редко замечают разницу в своем ежедневном просмотре. Но сколько вариаций мы увидели в изменившихся тестах? На диаграмме ниже показано среднее улучшение или снижение производительности в процентах.

Мы обнаружили, что отключение JIT не всегда имеет негативные последствия. Наши тесты, которые измеряли улучшение мощности, показали улучшение в среднем на 15%, а наши регрессии показали увеличение энергопотребления примерно на 11%. Память также неоднозначна: тесты с отрицательным воздействием показывают регресс на 2,3%, но больший выигрыш оказался у тестов, показавшие улучшения. Время загрузки страницы показывает наиболее сильное ухудшение с тестами, которые показывают регресс в среднем на ~17%. Однако на время запуска оказывает только положительное влияние и не приводит к регрессу.

Важно отметить, что эти результаты не включают Speedometer 2.0, наиболее часто упоминаемый эталонный тест. Отключение JIT действительно приводит к значительно более низким результатам в тестах JavaScript. Наши тесты показали снижение до 58%. Однако часто пользователи не замечают этого влияния, потому что этот тест показывает только часть общей истории производительности.

Итак, стоит ли прирост производительности, обеспечиваемый JIT, возникающих в результате ошибок безопасности, обновлений и упущенных мер безопасности? Ответ на этот вопрос зависит от нескольких факторов. Вы смотрите блог или играете в онлайн-игру? Вы посещаете надежный или ненадежный сайт? Продолжая этот эксперимент, мы постараемся изучить эти факторы и их влияние на наших пользователей.

Проект Super Duper Secure Mode

В течение следующих нескольких месяцев мы попытаемся ответить на эти вопросы с помощью нашего эксперимента с Super Duper Secure Mode (SDSM). Это займет некоторое время, но мы надеемся, что в процессе рендеринга будет защита CET, ACG и CFG. Как только это будет завершено, мы надеемся найти способ интеллектуального включения этих мер по снижению рисков, основанного на рисках, и дать пользователям возможность найти баланс между компромиссами.

В настоящее время SDSM отключает JIT (TurboFan/Sparkplug) и включает CET. На данный момент веб-сборка в этом режиме не поддерживается. Мы надеемся постепенно включить новые средства защиты и добавить поддержку веб-сборки в течение следующих нескольких месяцев по мере продолжения тестирования и экспериментов. Вы можете найти эту функцию в разд��ле edge://flags в Edge Canary, Dev и Beta.

Конечно, это всего лишь эксперимент; всё может измениться, и нам предстоит преодолеть немало технических проблем. Кроме того, наше шутливое название, вероятно, придется изменить на более профессиональное, когда мы запустим функцию. А пока мы продолжим получать от этого удовольствие.

Если вы решите протестировать эту функцию, отправьте нам свой отзыв через меню «Feedback» в Microsoft Edge. Нам не терпится узнать о вашем опыте.