Меры противодействия ненадежному коду
В начале 2018 года исследователи из Project Zero компании Google раскрыли новый класс атак, которые используют оптимизации спекулятивного исполнения, применяемые многими процессорами. Поскольку V8 использует оптимизирующий JIT-компилятор TurboFan для ускорения выполнения JavaScript, в определенных условиях он уязвим к атакам через побочные каналы, описанным в раскрытии.
Ничего не меняется, если вы выполняете только надежный код
Если ваш продукт использует встроенную версию V8 только для выполнения JavaScript- или WebAssembly-кода, который полностью находится под вашим контролем, то, вероятно, уязвимость Speculative Side-Channel Attacks (SSCA) не отслеживается в использовании V8. Примером такой безопасной среды может быть экземпляр Node.js, выполняющий только доверенный код.
Чтобы воспользоваться уязвимостью, злоумышленник должен выполнить тщательно разработанный JavaScript- или WebAssembly-код в вашей встроенной среде. Если как разработчик вы полностью контролируете код, выполняемый в вашей встроенной версии V8, то это маловероятно. Однако, если ваша встроенная версия V8 позволяет загружать и выполнять произвольный или ненадежный JavaScript- или WebAssembly-код, либо генерирует и впоследствии выполняет код JavaScript или WebAssembly, который не полностью находится под вашим контролем (например, использует их в качестве цели компиляции), вам следует рассмотреть меры защиты.
Если вы все же выполняете ненадежный код…
Обновите до последней версии V8, чтобы воспользоваться мерами защиты и включить их
Меры защиты от этого класса атак реализованы в V8 начиная с V8 v6.4.388.18, поэтому рекомендуется обновить вашу встроенную копию V8 до v6.4.388.18 или более поздней версии. Ранние версии V8, включая версии, которые все еще используют FullCodeGen и/или CrankShaft, не имеют защит от SSCA.
Начиная с V8 v6.4.388.18, в V8 был добавлен новый флаг, который помогает защититься от уязвимостей SSCA. Этот флаг, называемый --untrusted-code-mitigations
, включен по умолчанию во время выполнения через флаг GN на этапе сборки под названием v8_untrusted_code_mitigations
.
Эти меры защиты включаются флагом выполнения --untrusted-code-mitigations
:
- Маскирование адресов перед доступом к памяти в WebAssembly и asm.js, чтобы гарантировать, что спекулятивные загрузки памяти не могут получить доступ к памяти вне областей WebAssembly и asm.js.
- Маскирование индексов в JIT-коде, используемых для доступа к массивам и строкам JavaScript в спекулятивных путях выполнения, чтобы гарантировать, что спекулятивные загрузки не могут быть произведены с массивами и строками в адреса памяти, недоступные для JavaScript-кода.
Разработчики должны иметь в виду, что меры защиты могут иметь компромисс в производительности. Реальное влияние существенно зависит от вашей рабочей нагрузки. Для таких нагрузок, как Speedometer, влияние незначительное, но для более экстремальных вычислительных нагрузок оно может достигать 15%. Если вы полностью доверяете коду JavaScript и WebAssembly, который выполняет ваша встроенная версия V8, вы можете отключить эти меры защиты JIT, указав флаг --no-untrusted-code-mitigations
во время выполнения. Флаг GN v8_untrusted_code_mitigations
можно использовать для включения или отключения защит на этапе сборки.
Обратите внимание, что V8 по умолчанию отключает эти меры защиты на платформах, где предполагается, что разработчики будут использовать изоляцию процессов, например, на тех платформах, где Chromium использует изоляцию сайтов.
Песочница для ненадежного кода в отдельном процессе
Если вы выполняете ненадежный JavaScript- и WebAssembly-код в отдельном процессе от любых конфиденциальных данных, потенциальное влияние SSCA значительно снижается. Благодаря изоляции процессов атаки SSCA могут наблюдать только данные, находящиеся в той же песочнице процесса, что и выполняющийся код, а не данные из других процессов.
Рассмотрите настройку предлагаемых высокоточных таймеров
Высокоточный таймер облегчает наблюдение за побочными каналами в уязвимости SSCA. Если ваш продукт предлагает высокоточные таймеры, которые могут быть доступны ненадежному JavaScript- или WebAssembly-коду, рассмотрите возможность сделать эти таймеры более грубыми или добавить к ним джиттер.