Design: セキュリティについて説明する

やあ！

質問があります。このコンテキストで次のことを詳しく説明するのは理にかなっていますか。

「それ以外に、ソース言語レベルで未定義の動作を呼び出すプログラムは、アプリケーションヒープのコンテンツの破損、任意のパラメーターを使用したAPIの呼び出し、ハング、トラップ、または任意の量の消費など、他のことを行うWebAssemblyプログラムにコンパイルされる場合があります。リソース（制限内）。」
https://github.com/WebAssembly/design/blob/master/CAndC++.md#undefined-and-implementation-defined-behavior

私が考えているのは、例とさらなる議論を提供することによって、非ネイティブのバックグラウンドから来たWeb開発者に（おそらく）役立つかもしれないコンテキスト/リファレンスを提供することです。

たとえば、CERTの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。

wasmファイルを制御するための一意のCSPヘッダーがあると役に立ちますか？ サイトの所有者は、サブリソースがwasmをロードしないようにしたいと思うかもしれません。

それは興味深い質問です。 間違いなく、 evalとFunctionを許可しないのと同じ場合に、サイトがWebAssemblyの動的ロードと評価を許可しないようにする必要があります（これは、 LoaderでのES6モジュール統合とCSPチェックから外れるだけです。

ダイナミックリンクに関するセキュリティ上の懸念のいくつかについては、＃53を参照する価値があります。

@jfbastien yup CORSとSRIは、可能な場合は開発者が利用できるようにする必要があります。

@lukewagnerwasmが有効にするリソースへの低レベルのアクセスに依存すると思います。 あなたが箱から出して言うように、それはただのJSです。 ただし、wasmの包括的な目標は、可能な限り機械の金属に最も近いもののようです。 グローバルに制御するためのCSPディレクティブがあると便利です。
時間の経過とともに、他の機能へのよりきめ細かいアプローチも改善されるでしょう。

他の直接的な可能性は、他の低レベルのアクセスにアクセス許可APIを利用することです。

まあ、パフォーマンスの意味で金属に近い。 セキュリティ、権限、サンドボックスの観点から、WebAssemblyをJSから分岐させることについての議論はありません。

それは私がポストMVPとブレンダンアイクの発表の両方から得た感覚ではありませんでしたが、大丈夫です：+1：

あなたが言及しているのは、MVP後のWebAssemblyセマンティクスがJSで効率的にポリフィルできるものとは異なることが許可されることに同意したということだと思います。 この相違は、セキュリティ/許可とは関係なく、計算機能に関するものです。 つまり、それらを効率的にポリフィルすることはできませんでしたが、JS（ Emterpreterスタイル）で記述されたWebAssemblyインタープリターによって新しい機能をシミュレートすることができました。 この効果にメモを追加して、「JSからの分岐」の意味を制限するとよいでしょう。

うん、それは確かにドキュメントの良い拡張になるでしょう、私はドキュメントをあまりにも速く読んだかもしれませんが、それはそれを明確にしないようでした。

スレッド機能とメモリ機能を追加することについてのEichsの話のひとつで、wasmに新しい機能が追加されると思いました。 これらもJavaScriptに追加される可能性が高く、通常の新機能の精査の対象になると思います。

「セキュリティPOVとJSの違いはありません」がWeb.mdに追加され

私はむしろその区別をよりよく説明したいと思います。 JSを参照することは、自立の観点からはあまり良くありません。実際には、JSが持つセキュリティの表面積を減らしたいと思います（たとえば、クロスオリジンスクリプトなど）。

CppConで話をしたので、これについて説明します:-)

暗号化実装のターゲットとしてWebAssemblyを使用することに関心がある場合は、固定時間実装のサポートに関してJS / asm.jsJITとWebAssemblyJITの違いを詳しく説明すると便利です。 特に、ビットシフト、JIT後のブランチ、条件付きジャンプやルックアップ、またはタイミングリークを引き起こす可能性のあるJITによるその他の変更などの操作について考えています。

開発者がWebAssemblyがasm.jsですでに持っているものよりも固定時間の実装をより適切にサポートすることを期待していない場合は、アプリケーション設計に対するWebAssemblyのセキュリティへの影響を詳しく説明する一環として役立つと述べてください。 WebAssemblyが、現在存在するものよりもアプリケーションを強化するための何らかの手段を提供するのであれば（現在、またはMVPの後で、仕様を詳しく読んでいません）、それについても詳しく説明するのは素晴らしいことです。 https://github.com/jedisct1/libsodium.js/issues/24#issuecomment -128002942には、クライアント側のJavaScript暗号に関する既存の問題に関する詳細があります。

ちなみに、これはすべて非常にエキサイティングです。 ：NS

@dconnollyによって提案された明確なステートメントが必要であることに同意しました。 今のところ、MVPの場合、JITが実行できること、実行できないことは保証されておらず、少なくともMVPの場合、定数時間アルゴリズムはwasmの適切な使用法ではないという議論がありました。 これは将来変更される可能性があります。

私の現在の見解は、適切な一定時間のコードを作成するには、マイクロアーキテクチャのアセンブリと十分な理解が必要になることが多いため、外部API（Webプラットフォームなどのエンベッダーによって提供される）がそのような保証を提供するのに適しているということです。 動的バイナリ変換を実行するCPUの極端な例を考えてみましょう。WebAssemblyは、CPUが実行できること/実行できないことを保証できません。 私の見解では、WebAssemblyは抽象化レベルが高すぎて、真の一定時間コードを表現できません。

かっこいい、説明してくれてありがとう。 WebプラットフォームAPIは、この種のもの、特にプリミティブに最適な場所であることに同意しました（ メモを介した新しい楕円曲線などの将来の追加の余地がある、基本をサポートしてい

@ jfbastien 、wasmのタイミング保証についてあなたが言ったことはすべて今日でも当てはまりますか？

現在のドキュメントでは、定数時間アルゴリズムに対して潜在的にポジティブに聞こえる、文書化されたエッジケースの小さなリストを除いて、決定論的実行が目標であることがわかります。 ただし、 webassembly.org / docs / securityは、タイミング攻撃の可能性を認めており、将来の潜在的な緩和策をいくつか示していますが、「バグのあるCコードが魔法のように修正されない...まだ」または「通常のCコンパイラでは発生しないサイドチャネルの脆弱性が導入される可能性があります」。

厳しい保証はさておき、少なくとも「定数時間アルゴリズムは100％確実に失敗する」と「clangのネイティブバイナリ出力に匹敵するタイミング特性を常に期待しない明確な理由はない」の間にあることを理解することは役に立ちます。 @dconnollyの指摘に'use asm'ステートメントを完全に尊重するFirefoxのような実装と、少し緩く再生するChromeのような実装の両方を考慮に入れると便利です。 。

@ buu700のすべてのオペコードの決定論的結果は、どのオペコードでもタイミングが保証されていることを意味するものではありません。 Clangは一定時間の実行も保証しません。また、情報漏えいの影響を受けやすいコードを作成している場合は、一定時間だけでは不十分です。

現在、WebAssemblyはinfoleaksに関して何も保証しようとはしていません。

了解しました。決定論@jfbastienのセクションを明確にしていただきありがとうございます。

タイミング/サイドチャネル（および保証またはその欠如を無視する）に関しては、現時点では仕様に関連するものはなく、実際の実装がclangとどのように比較されるかについての有用なデータはまだないようです。 以前のコメントを読んだ後、私が実際に得たのは、wasmの実装がこの領域でgcc / clangよりも常に_悪い_であるという固有の理由があるかどうかです。 懸念事項として抽象化のレベルについて言及しましたが、「十分に良い」一定のタイミング（ネイティブC、アセンブリ、ハードウェアなど）のベースライン比較として何を使用しているかが明確ではありませんでした。

言い換えれば、clangでインフォリークに敏感なコードを実行するか、今日のWebAssembly仕様の仮想的な最良/最も成熟した/最もインフォリークが強化された実装のどちらかを選択した場合、あなたの理解に基づいて、前者が明らかに好まれますか？

現時点では、infoleakに敏感なコードについては、clangにもWebAssemblyにも依存していません。 私が望む保証を実際に得るために現在私が知っている唯一の方法は、私がターゲットにしている特定のCPUのマニュアルを読むアセンブリを作成し、カーネルと緊密に連携することです。 本当にタイミングに依存しないようにしたい場合は、「x86」または「ARM64」を知っているだけでは十分ではありません。

一部のコンパイラ/言語でいくつかの保証を得ることができますが、コードを無効にするために必要な情報リークが1つだけの場合、「一部」では十分な保証はありません。

完璧です、ありがとう、それが私の質問に答えると思います。 一般的なインフォリーク脅威モデリングに関するすべての点で合意しました。 wasmを他の（asmフリーの）Cコンパイルターゲットよりもリークが多いと見なすべきかどうかを知りたかっただけですが、必ずしもそうではないということですか？

「もっと漏れやすい」というのは役に立たないと思います。 指標は「漏れはありませんか？」です。 WebAssembly、clang、C ++、およびCの答えは「はい」です。

特に、私が念頭に置いていたのは、@ dconnollyによってリンクされたlibsodium / NaClの例など、純粋なC実装で特定のサイドチャネル抵抗特性を実現するように設計されたアルゴリズムでした。 考えられるすべての攻撃シナリオで何かが生き残ることができれば確かに理想的ですが、2つのものの間のデルタを知ることも役立ちます（両方が吸う場合でも、ある程度吸うことによって）、この場合、LinuxABIの代わりにWebAssemblyを使用するかどうかターゲットは、libsodiumの意図された脅威モデルを破る可能性があります。

libsodiumの問題スレッドに関するリンクされたコメントは、ライブラリがasm.jsとどのように相互作用するかについて非常に有益ですが、専門家ではないため、その特定の分析がWebAssembly用に書き直されたように聞こえるかどうかはわかりません（i64サポートとブラウザーがasm.jsよりもwasmの処理の一貫性があります）。

しかし、とにかく、私はあなたの元のポイントが1年前から何であったかを理解しています、そして私が本当に心配したのはあなたが実際よりも強い発言をしていたかどうかだけでした（それは仕様が特定の新しいサイドチャネルの弱点を導入することが知られていましたどちらも一般的にその目的に適していないのとは対照的に、標準の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のようなものと同じくらいリークする可能性が高いと思います。 最終的には、特にパフォーマンスを犠牲にすることなく、仕様や実装者が情報漏えいの防止に対応しようと努力する可能性は低いと思います。