Design: Объясните безопасность

Привет!

У меня вопрос: имеет ли смысл в этом контексте подробно остановиться на следующем:

«Помимо этого, программы, которые вызывают неопределенное поведение на уровне исходного языка, могут быть скомпилированы в программы WebAssembly, которые делают что-нибудь еще, включая повреждение содержимого кучи приложения, вызов API-интерфейсов с произвольными параметрами, зависание, захват или потребление произвольного количества ресурсы (в пределах) ".
https://github.com/WebAssembly/design/blob/master/CAndC++.md#undefined-and-implementation-defined-behavior

Я думаю о предоставлении контекста / ссылок, которые могут (возможно) быть полезными для веб-разработчиков, пришедших из неродных фонов - путем предоставления примеров и дальнейшего обсуждения.

Например, MSC14-C. ненужные зависимости платформы, в котором перечислены четыре различных типа непереносимого поведения (неопределенное поведение, неопределенное поведение, поведение, зависящее от локали, поведение, определяемое реализацией) с примерами. MSC15-CPP. Компиляторы C могут молча отказаться от некоторых циклических проверок , которые могут быть особенно примечательными в этом контексте (Роберт Сикорд обсуждает это более подробно в «Тихом устранении проверок границ» ).

Более подробные процедуры:

• Что каждый программист на C должен знать о неопределенном поведении # 1/3
• Что каждый программист на C должен знать о неопределенном поведении # 2/3
• Что каждый программист на C должен знать о неопределенном поведении # 3/3
• Руководство по неопределенному поведению в C и C ++, часть 1
• Руководство по неопределенному поведению в C и C ++, часть 2
• Руководство по неопределенному поведению в C и C ++, часть 3

Другой потенциально важный совет:

• INT02-CPP.
• INT08-CPP.
• INT10-CPP.
• INT18-C.
• INT32-C.

Помогло бы наличие уникального заголовка CSP для управления файлами wasm? Я чувствую, что владельцы сайтов могут захотеть запретить подресурсам загружать wasm.

Это интересный вопрос. Определенно мы должны разрешить сайтам запрещать динамическую загрузку и оценку WebAssembly в тех же случаях, когда они запрещают eval и Function (это просто выпадет из-за интеграции модуля ES6 и проверки CSP на Loader путь). Однако в прошлом, поскольку WebAssembly будет эквивалентен JS по возможностям, я бы не подумал, что их нужно различать.

Стоит указать на № 53, где обсуждаются некоторые проблемы безопасности при динамическом связывании.

@jfbastien да CORS и SRI должны быть доступны разработчикам там, где это возможно.

@lukewagner Я думаю, это зависит от низкоуровневого доступа к ресурсу, который будет разрешен wasm. Как вы говорите из коробки, это просто JS. Однако кажется, что главная цель wasm - это как можно более близкое к металлическим машинам; было бы неплохо иметь директиву CSP для глобального управления.
Со временем будет лучше и более детальный подход к другим функциям.

Другие непосредственные возможности - использование API разрешений для другого низкоуровневого доступа.

Что ж, близко к металлу в смысле производительности. С точки зрения безопасности, разрешений и изолированности, не обсуждается отклонение WebAssembly от JS.

Это было не то чувство, которое у меня возникло от анонсов пост-MVP и Брендана Эйха, но ладно: +1:

Я думаю, вы имеете в виду то, что мы договорились о том, что после MVP семантика WebAssembly может отличаться от того, что может быть эффективно полифилировано в JS. Это расхождение связано с вычислительными функциями, а не с безопасностью / разрешениями. Это означает, что, хотя их нельзя _эффективно_ полифилировать, новые функции _ могут_ имитироваться интерпретатором WebAssembly, написанным на JS (в стиле Emterpreter ). Вероятно, было бы хорошо добавить примечание к этому эффекту, чтобы ограничить то, что мы подразумеваем под «отклонением от JS».

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

Я думаю, что это был один из разговоров Эйха о добавлении дополнительных функций многопоточности и памяти, который заставил меня подумать, что wasm получит новые функции. Я подозреваю, что они, вероятно, также будут добавлены в JavaScript и станут предметом обычного изучения новых функций.

«Не отличается от безопасности POV, чем JS» теперь на Web.md.

Я лучше объясню разницу. Ссылаться на JS не очень хорошо с точки зрения отдельного человека, и я думаю, что мы действительно хотим уменьшить область безопасности, которую имеет JS (скажем, скрипты с перекрестным происхождением и т. Д.).

Я перейду к этому, теперь, когда я говорил об этом на CppCon :-)

Для тех, кто может быть заинтересован в использовании WebAssembly в качестве цели для криптографических реализаций, будет полезно подробнее рассказать о различиях между JS JS / asm.js и WebAssembly JIT с точки зрения поддержки реализаций с фиксированным временем. Я думаю конкретно о таких операциях, как сдвиги битов, ветвления, введенные после JIT, условные переходы или поиски, или другие изменения, которые может внести JIT, которые могут вызвать утечки времени.

Если разработчики не должны ожидать, что WebAssembly будет лучше поддерживать реализации с фиксированным временем, чем то, что мы уже имеем с asm.js, то заявление об этом было бы полезным в рамках разработки вопросов безопасности WebAssembly для проектирования приложений. Если WebAssembly предоставит некоторые средства для улучшения защиты приложений по сравнению с существующими в настоящее время (сейчас или после MVP, я не читал подробно спецификацию), было бы неплохо подробнее остановиться на этом. https://github.com/jedisct1/libsodium.js/issues/24#issuecomment -128002942 содержит дополнительную информацию о существующих проблемах, связанных с криптографией JavaScript на стороне клиента.

Между прочим, все это очень увлекательно. : D

Решили, что у нас должно быть уточняющее заявление, предложенное @dconnolly. На данный момент мы обсуждали, что для MVP не будет никаких гарантий того, что JIT может / не может делать, и что алгоритмы с постоянным временем не являются правильным использованием wasm, по крайней мере, для MVP. Это может измениться в будущем.

В настоящее время я считаю, что внешние API-интерфейсы (предлагаемые устройством для внедрения, например веб-платформой) лучше подходят для предоставления таких гарантий, поскольку вам часто требуется сборка и хорошее понимание микроархитектуры для написания правильного кода с постоянным временем. Рассмотрим крайний пример, когда ЦП выполняет динамическую двоичную трансляцию: WebAssembly не может гарантировать, что ЦП может / не может делать. Я считаю, что WebAssembly находится на слишком высоком уровне абстракции, чтобы выразить истинный постоянный код.

Круто, спасибо за разъяснения. Согласны с тем, что API веб-платформы - лучшее место для такого рода вещей, особенно примитивов ( WebCrypto поддерживает / будет поддерживать самое необходимое, с местом для будущих дополнений, таких как новые эллиптические кривые с помощью примечаний ). С нетерпением ждем этого дополнительного языка по безопасности, он поможет всем, кто может неверно истолковать значение WebAssembly. : +1:

@jfbastien , все ли, что вы сказали о гарантиях времени wasm, действует и сегодня?

В текущих документах я вижу, что детерминированное выполнение является целью, за исключением небольшого списка задокументированных крайних случаев, что звучит потенциально положительно для алгоритмов с постоянным временем. Тем не менее, webassembly.org/docs/security признает, что временные атаки возможны, и перечисляет некоторые потенциальные будущие смягчения, но неясно, подразумевается ли это, что «ваш ошибочный код C не будет исправлен волшебным образом ... тем не менее, могут появиться «или» уязвимости побочного канала, которых не было бы с типичным компилятором C ».

Помимо жестких гарантий, было бы полезно по крайней мере понять, где мы находимся между «алгоритмы постоянного времени на 100% определенно ошибаются» и «нет очевидной причины не всегда ожидать, что временные характеристики сопоставимы с собственным двоичным выводом clang». По мнению @dconnolly , некоторый язык, специально сравнивающий это с asm.js, также был бы действительно полезен - особенно с учетом обеих реализаций, таких как Firefox, которые полностью уважают операторы 'use asm' и таких, как Chrome, которые играют немного слабее .

Детерминированный результат

Прямо сейчас WebAssembly не пытается гарантировать что-либо в отношении утечки информации.

Понятно, спасибо за разъяснения в разделе о детерминизме @jfbastien.

Что касается таймингов / побочных каналов (и игнорирования гарантий или их отсутствия), похоже, что в настоящее время в спецификации нет ничего значимого по этому поводу, и пока нет полезных данных о том, как фактические реализации сравниваются с clang? Что я действительно понял после прочтения вашего предыдущего комментария, так это то, есть ли внутренняя причина, по которой реализации wasm обязательно всегда _ хуже_, чем gcc / clang в этой области. Вы упомянули уровень абстракции как предмет для беспокойства, но было непонятно, что вы использовали в качестве базового сравнения для «достаточно хорошей» постоянной синхронизации (собственный C, сборка, оборудование и т. Д.).

Другими словами, учитывая выбор между запуском кода, чувствительного к утечке информации, на clang и гипотетической лучшей / наиболее зрелой / наиболее защищенной от утечки возможной реализацией сегодняшней спецификации WebAssembly, будет ли первое все же очевидно предпочтительным, исходя из вашего понимания?

На данный момент я бы не стал полагаться ни на clang, ни на WebAssembly для кода, чувствительного к утечке информации. На данный момент я знаю, что единственный способ получить желаемые гарантии - это написать сборку, читая руководство для конкретного процессора, на который я нацелен, и в тесном сотрудничестве с ядром. Знания «x86» или «ARM 64» даже недостаточно, если вы действительно хотите быть независимым от времени.

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

Отлично, спасибо, думаю, это ответ на мой вопрос. Согласованы по всем пунктам об общем моделировании угроз инфо-утечки; Я просто хотел понять, следует ли считать wasm более негерметичным, чем любая другая (без asm) цель компиляции C, что, похоже, вы говорите, не обязательно так?

Я не думаю, что «больше дырявых» - это полезная мера. Метрика - "утечки вообще?" Ответ для WebAssembly, clang, C ++ и C - «да».

Что ж, в частности, я имел в виду алгоритмы, разработанные для достижения определенных свойств сопротивления бокового канала с помощью чистых реализаций C, таких как пример libsodium / NaCl, связанный с помощью @dconnolly. Конечно, идеально, если что-то переживет все возможные сценарии атаки, но также полезно знать разницу между двумя вещами (даже если они оба отстойны, в некоторой степени отстой), и в этом случае использовать WebAssembly вместо Linux ABI в качестве цель может нарушить предполагаемую модель угрозы libsodium.

Связанный комментарий к теме проблемы libsodium очень информативен относительно того, как библиотека взаимодействует с asm.js, но, как неспециалисту, мне не очевидно, как этот конкретный анализ будет звучать, как переписанный для WebAssembly (помимо поддержки i64 и браузеров, которые более последовательная обработка wasm, чем asm.js).

Но в любом случае, я понимаю, какова была ваша исходная точка зрения год назад, и все, что меня действительно беспокоило, было то, делали ли вы более сильное заявление, чем вы на самом деле не встречается в стандартном C / clang, в отличие от того, что ни один из них обычно не подходит для этой цели), поэтому спасибо за пояснение.

>

Я не думаю, что «больше дырявых» - это полезная мера.

@jfbastien , количественная безопасность - это область измерения
что. Общая метрика - это то, сколько битов информации раскрывает
успешная атака - 1 бит против 32 бит, скажем, имеет огромное значение (и в
на практике почти каждая система имеет небольшие потенциальные утечки через боковые стороны
каналы). Однако зачастую такое количественное определение довольно сложно.

>

Я не думаю, что «больше дырявых» - это полезная мера.

@jfbastien , количественная безопасность - это область измерения
что. Общая метрика - это то, сколько битов информации раскрывает
успешная атака - 1 бит против 32 бит, скажем, имеет огромное значение (и в
на практике почти каждая система имеет небольшие потенциальные утечки через боковые стороны
каналы). Однако зачастую такое количественное определение довольно сложно.

Я знаю об этом и совершенно не заинтересован, потому что утечка - это утечка. Если это важно для разработчиков, то в конечном итоге нас (разработчиков WebAssembly) укусит. Я не думаю, что WebAssembly должен пытаться решить эту проблему в ближайшее время, учитывая другие наши приоритеты, и что WebCrypto уже существует как усилие (несмотря на недостатки, которые он может иметь в противном случае, решение этой проблемы лучше, чем то, где сейчас находится WebAssembly. ). Вы, конечно, можете изучить это на досуге.

@jfbastien , согласился, что эта тема сейчас не имеет приоритета, что
Wasm не более дырявый, чем C, и мы не знаем хороших способов справиться с этим.
Это. Но такие чрезмерные упрощения, как «утечка - это утечка», здесь не помогают.
имеет значение - каждая система в той или иной степени протекает, поэтому на самом деле количество
это имеет значение. И просто ждать, пока "он нас не укусит" - это не стратегия,
вызовет большое доверие у реальных потенциальных жертв, а именно
пользователи браузера.

согласился, что ... Wasm не более дырявый, чем C

Отлично, спасибо за явное подтверждение! Это все, ради чего я пришел: общее представление о том, с чем я должен его сравнивать, а не гарантия того, что он «не протечет».

@ rossberg-chromium Не думаю, что я согласен с идеей, что wasm не более дырявый, чем C. В конце концов, это зависит от того, как каждый движок все реализует. Например, JavaScriptCore повышает уровень кода и прекращает выравнивание кода, когда ему не хватает исполняемой памяти. Это утечка, которой нет в коде C. Я ожидал, что по мере того, как двигатели wasm станут более продвинутыми, wasm, вероятно, будет столь же негерметичным, как что-то вроде JVM. В конечном счете, я не знаю, что спецификация или разработчики, вероятно, будут стремиться предотвратить утечку информации, особенно не за счет производительности.