スキップしてメインコンテンツへ

WebAssemblyのセキュリティ、現在および将来

投稿: 2021年3月23日お知らせ

By Marco Fioretti

前書き

WebAssemblyは、私たちと同じように 最近説明した、任意の言語で記述されたソフトウェアのバイナリ形式であり、最終的には変更なしで任意のプラットフォームで実行されるように設計されています。 WebAssemblyの最初のアプリケーションは、Webブラウザー内にあり、Webサイトをより高速でインタラクティブにします。あらゆる種類のサーバーからモノのインターネット(IoT)まで、WebAssemblyをWebを超えてプッシュする計画は、セキュリティの問題と同じくらい多くの機会を生み出します。この投稿は、これらの問題とWebAssemblyセキュリティモデルの概要です。

WebAssemblyはJavaScriptのようなものです

Webブラウザー内では、WebAssemblyモジュールはJavaScriptコードを実行するのと同じ仮想マシン(VM)によって管理されます。したがって、WebAssemblyを使用すると、JavaScriptで実行できるのと同じ害の多くを、より効率的かつ目に見えない形で実行できます。 JavaScriptはブラウザーがコンパイルするプレーンテキストであり、WebAssemblyはすぐに実行できるバイナリ形式であるため、後者は実行速度が速く、悪意のある命令をスキャンすることも(ウイルス対策ソフトウェアによっても)困難です。

WebAssemblyのこの「コード難読化」効果は、特に、不要な広告をポップアップしたり、機密データを要求する偽の「テクニカルサポート」ウィンドウを開いたりするためにすでに使用されています。もう1つのトリックは、本当に危険なマルウェアを含む「ランディング」ページにブラウザを自動的にリダイレクトすることです。

最後に、WebAssemblyは、JavaScriptと同様に、データの代わりに処理能力を「盗む」ために使用できます。 2019年には、 150の異なるWasmモジュールの分析32% それらの内、暗号通貨マイニングに使用されました。

WebAssemblyサンドボックスとインターフェース

WebAssemblyコードは閉じて実行されます サンドボックス オペレーティングシステムではなく、VMによって管理されます。これにより、ホストコンピュータの可視性、またはホストコンピュータと直接対話する方法が提供されません。ファイル、ハードウェア、インターネット接続などのシステムリソースへのアクセスは、そのVMによって提供されるWebAssemblyシステムインターフェイス(WASI)を介してのみ行うことができます。

WASIは、他のほとんどのアプリケーションプログラミングインターフェイスとは異なり、サーバー/エッジコンピューティングシナリオでのWASMの採用を真に推進している独自のセキュリティ特性を備えており、次の投稿のトピックになります。ここでは、Webから他の環境に移行するときに、セキュリティへの影響が大きく異なると言えば十分です。最新のWebブラウザーは非常に複雑なソフトウェアですが、数十年の経験と数十億人の毎日のテストに基づいています。ブラウザと比較して、サーバーやIoTデバイスはほとんど未知の土地です。これらのプラットフォームのVMには、WASIの拡張が必要であるため、新しいセキュリティの課題が確実に発生します。

WebAssemblyでのメモリとコードの管理

通常のコンパイル済みプログラムと比較して、WebAssemblyアプリケーションはメモリへのアクセスとそれ自体へのアクセスが非常に制限されています。 WebAssemblyコードは、まだ呼び出されていない関数や変数に直接アクセスしたり、任意のアドレスにジャンプしたり、バイトコード命令としてメモリ内のデータを実行したりすることはできません。

ブラウザ内では、Wasmモジュールは連続したバイトのグローバル配列(「線形メモリ」)を1つだけ取得して操作します。 WebAssemblyは、その領域内の任意の場所を直接読み書きしたり、サイズの拡大を要求したりできますが、それだけです。この線形メモリは、実際のコード、実行スタック、そしてもちろんWebAssemblyを実行する仮想マシンを含む領域からも分離されています。ブラウザの場合、これらのデータ構造はすべて通常のJavaScriptオブジェクトであり、標準の手順を使用して他のすべてのオブジェクトから分離されています。

結果:良いが完璧ではない

これらすべての制限により、WebAssemblyモジュールの誤動作は非常に困難になりますが、不可能ではありません。

WebAssemblyが何に触れることをほとんど不可能にするサンドボックスメモリ 外側 また、オペレーティングシステムが悪いことが起こるのを防ぐのが難しくなります 内部。次のような従来のメモリ監視メカニズム 「スタックカナリア」、一部のコードが触れてはならないオブジェクトをいじろうとした場合に気付く、 そこでは働けない.

WebAssemblyがアクセスできるのは独自の線形メモリのみであるという事実だけでなく、直接アクセスすることもできます。 促進する 攻撃者の仕事。これらの制約とモジュールのソースコードへのアクセスにより、どのメモリ位置を上書きして最大の損害を与えることができるかを推測するのがはるかに簡単になります。それもそうです 可能 ローカル変数は線形メモリの教師なしスタックにとどまるため、ローカル変数を破損します。

に関する2020年の論文 WebAssemblyのバイナリセキュリティ WebAssemblyコードは、おそらく定数メモリ内の文字列リテラルを上書きできることに注意してください。同じペーパーで、3つの異なるプラットフォーム(ブラウザー、Node.js上のサーバー側アプリケーション、スタンドアロンWebAssembly VM用のアプリケーション)でWebAssemblyをネイティブバイナリにコンパイルする場合よりも安全性が低い可能性がある他の方法について説明し、さらに推奨します。このトピックを読んでいます。

一般に、WebAssemblyがそれ自体のサンドボックス内にあるものにのみ損傷を与えることができるという考えは、誤解を招く可能性があります。 WebAssemblyモジュールは、それらを呼び出すJavaScriptコードに対して重い作業を行い、毎回変数を交換します。 WebAssemblyを呼び出した安全でないJavaScriptでクラッシュやデータ漏洩を引き起こす可能性のあるコードをこれらの変数のいずれかに書き込むと、これらのことが起こります。 意志 起こります。

前方の道路

確かにセキュリティに影響を与えるWebAssemblyの2つの新しい機能(どの程度、どれだけ、伝えるのは時期尚早です)は次のとおりです。 並行性、および内部ガベージコレクション。

同時実行性は、複数のWebAssemblyモジュールを同じVMで同時に実行できるようにするものです。今日、これはJavaScriptを介してのみ可能です Webワーカー、しかしより良いメカニズムが開発中です。セキュリティ面では、彼らは持ち込む可能性があります 「多くのコード…以前は必要なかった」、それは物事がうまくいかないためのより多くの方法です。

ネイティブガベージコレクター パフォーマンスとセキュリティを向上させるために必要ですが、何よりも、十分にテストされたブラウザのJava VMの外部でWebAssemblyを使用し、とにかく内部のすべてのゴミを収集します。もちろん、この新しいコードでさえ、バグや攻撃の別のエントリポイントになる可能性があります。

良い面としては、WebAssemblyを現在よりもさらに安全にするための一般的な戦略も存在します。から再度引用 こちら、コンパイラの改善が含まれています、 分ける スタック、ヒープ、定数データ用の線形メモリ。WebAssemblyモジュールコードとして「Cなどの安全でない言語」でコンパイルすることを回避します。

Linux Foundationのトレーニングと認定に関心をお寄せいただきありがとうございます。私たちは、中国のトレーニングサイトからより良いサービスを提供できると考えています。このサイトにアクセスするには、以下をクリックしてください。

Linux Foundationのカルチャに対するフィードバックは、より適切に、中国のカルチャウェブサイトに反映されることを期待しています。