プレビュー版 Microsoft Edge のセキュリティ強化モード「Super Duper Secure Mode」 46
ストーリー by headless
強化 部門より
強化 部門より
Microsoft Browser Vulnerability Research (VR) チームがプレビュー版の Microsoft Edge でテスト中のセキュリティ強化モード「Super Duper Secure Mode (SDSM)」について解説している(VR のブログ記事、 The Verge の記事、 On MSFT の記事、 The Register の記事)。
Web ブラウザーに対する攻撃の主なターゲットは JavaScript エンジンのバグだ。中でもパフォーマンスを向上させる「JIT (Just-In-Time Compilation)」に関連する問題が大きな割合を占め、V8 に関する脆弱性で 2019 年以降に発行された CVE の 45 % を JIT エンジンが占めているという。さらに、Intel によるハードウェアベースのエクスプロイト緩和技術 Control-flow Enforcement Technology (CET) のように、V8 JIT と共存させることのできない脆弱性緩和技術も多い。
SDSM は JIT を無効化して脆弱性緩和技術を有効化するというもので、現在の SDSM では 2 つの JIT (TurboFan / Sparkplug)を無効化するとともに、CET が有効化される。パフォーマンス向上技術の JIT だが、無効化しても通常のブラウジングで体感できるような差は出ないようだ。今後はさらなる脆弱性緩和技術の有効化や、Web Assembly サポートの追加を行う計画だという。
SDSM を有効にするには、プレビュー版 Microsoft Edge (Bata / Dev / Canary) で「試験段階の機能 (edge://flags)」の「Super Duper Secure Mode (edge://flags/#edge-enable-super-duper-secure-mode)」を「Enabled」にしてブラウザーを再起動すればいい。
VR チームでは SDSM プロジェクトを楽しんで進めていく計画で、公式にするにはまだ早すぎることもあって面白い名前を付けたとのことだ。
Web ブラウザーに対する攻撃の主なターゲットは JavaScript エンジンのバグだ。中でもパフォーマンスを向上させる「JIT (Just-In-Time Compilation)」に関連する問題が大きな割合を占め、V8 に関する脆弱性で 2019 年以降に発行された CVE の 45 % を JIT エンジンが占めているという。さらに、Intel によるハードウェアベースのエクスプロイト緩和技術 Control-flow Enforcement Technology (CET) のように、V8 JIT と共存させることのできない脆弱性緩和技術も多い。
SDSM は JIT を無効化して脆弱性緩和技術を有効化するというもので、現在の SDSM では 2 つの JIT (TurboFan / Sparkplug)を無効化するとともに、CET が有効化される。パフォーマンス向上技術の JIT だが、無効化しても通常のブラウジングで体感できるような差は出ないようだ。今後はさらなる脆弱性緩和技術の有効化や、Web Assembly サポートの追加を行う計画だという。
SDSM を有効にするには、プレビュー版 Microsoft Edge (Bata / Dev / Canary) で「試験段階の機能 (edge://flags)」の「Super Duper Secure Mode (edge://flags/#edge-enable-super-duper-secure-mode)」を「Enabled」にしてブラウザーを再起動すればいい。
VR チームでは SDSM プロジェクトを楽しんで進めていく計画で、公式にするにはまだ早すぎることもあって面白い名前を付けたとのことだ。
WebAssemblyが普及したら (スコア:1)
Re: (スコア:0)
WebAssemblyができることは、Javascriptと変わらない
何がいいたいんだ？
Re:WebAssemblyが普及したら (スコア:1)
WebAssemblyもJITなしなのか、それとも別のやり方になるのか…。
Re: (スコア:0)
記事にwebassemblyサポート追加と書いてんだからJITのの取り外しに対応するんじゃない?
Re: (スコア:0)
そだっけJSの方ができることが多かったような
Re: (スコア:0)
何が？
Re: (スコア:0)
ここ数年ほとんどウェブアセンブリのことを調べたことは無かったが、ウェブアセンブリが結局JIT使うなら、おれが望んでいたものとだいぶ違うな。Ahead of Time コンパイルで最初から直接動くコードを読み込んで最速を目指すのがそれの目的かと思ったら、JavaScriptの構文解析のコストを下げるだけで終わってしまうのか。ブラウザから直接マシンコード読み込んで動かすことのなにがいけないのだろうか。<script src=xxx.js> のかわりに <exec code=x86:xxx.dll,armv8:xxx.armv8.so> みたいな感じで。サーバーで長々と動かすソフトウェアならゆるゆる最適化、実行中にコードを並び替えるのもいいかもしれないが、端末でそれやると非効率だ。
Re: (スコア:0)
ブラウザから直接マシンコード読み込んで動かすことのなにがいけないのだろうか。<script src=xxx.js> のかわりに <exec code=x86:xxx.dll,armv8:xxx.armv8.so> みたいな感じで。
Google NaClがそんな感じの仕組みだった。だから、NaCl→pNaCl→WebAssemblyの流れを調べれば、その疑問の答えが分かるのではないかと予想している。誰か調べて教えてほしい。
Re: (スコア:0)
アーキテクチャが増えるたびに誰がどうメンテするのって話になるのでしょう。
だから、pNaClの時点で中間コードになった。
今でもx86,x64,ARM,MIPSがあるし、RISC-Vとかも多分要考慮。
x86/64と一口に言ってもSSEやAVXとか環境によってサポート具合が異なる。
しかも、サイト側がユーザーのアーキテクチャ向けのバイナリを用意しなければ動かない。
バイナリなし環境でも動くように救おうとしたら、アーキテクチャ分ののバイナリ変換プログラムの保守が必要になって、テストは指数関数的に増える。
そんな面倒な事やってられねーので、今の形になったと思う。
Re: (スコア:0)
コードをあんまり具象化すると、AMDの拡張命令が使えるかとかAppleのSoCのコプロセッサが使えるかどうかとか
判定をsoやdllの中で網羅していかないといかなくて不便な気がする。
(既存のコード資産は、判定をsoやdllまで持ってきてるのもあれば、#ifdefなんかで落ちるのもあるんじゃない)
コードの中で判定するのは人手がかかるし、ファットバイナリは簡単だが通信量が増える
Re: (スコア:0)
> ブラウザから直接マシンコード読み込んで動かすことのなにがいけないのだろうか。
セキュリティの観点からはどっちもダメなのでは。その場で生成するのはダメだけどそのまま実行するのはいいという理由はない
Re:WebAssemblyが普及したら (スコア:1)
JITでは一般的にメモリページの属性を読み書き実行可能(RWX)にするので、任意メモリ書き換えできる脆弱性が即座に任意コード実行に変化しがち。それよりは事前に問題無いと検証できているAOTコードの実行のほうがRWXページ不要なので安全という見方ができると思う。
なお、その点でFirefoxのJITは工夫している。ページ属性を適宜RWとRXと変更し、RWXを使わないようにしている。
Firefox: W^X JIT-code が有効になりました
https://dev.mozilla.jp/2016/04/wx-jit-code-enabled-in-firefox/ [mozilla.jp]
これがGoogleが言い出したことなら (スコア:1)
「『セキュリティのためにJavaScriptは切る』という説はもう古い」というキャンペーンの準備かな、とも思うが
Microsoftならそこまでのことはあるまい(邪悪さという意味でもJavaScriptへの依存度的にも)
JIT無効化の方は前からある機能 (スコア:1)
CETのサポートはMSの独自機能かもしれませんが、JIT無効化は2年前にリリースされたV8 JavaScript engine v7.4で実装済みの機能 [v8.dev]ですね。(解説記事 [v8.dev])
JIT無効化はV8の機能なのでChromium系の他のブラウザでも使用できると思います。
追記 (スコア:0)
Chromium系ブラウザでJITを無効にするには、以下を追加して起動する
--js-flags="--jitless"
参考
https://github.com/GrapheneOS/Vanadium/blob/11/patches/0078-JIT-less-t... [github.com]
デュアル (スコア:0)
スラドなんかJavascript性能いらないから、単純で遅いけどセキュアなJavascriptエンジンと高速なJITのJavascriptエンジンの二本立てにして、サイトで切り替えればいいのに、と思った。
二つ維持したくないというのはあるかもしれないが。
Re: (スコア:0)
と書いてから、本文を最後まで読むと、JITエンジン部分とその他の部分が分離されていて、JITエンジン部分だけ無効化できるのね。
Re:デュアル (スコア:1)
「無効化しても通常のブラウジングで体感できるような差は出ない」とあるので、そこまでする必要すらないんじゃないかな
一年後には (スコア:0)
Super Dojikko Secure Modeと呼ばれていそう
Re: (スコア:0)
じっとしていられない？
仮想マシンで動かさないの？ (スコア:0)
ブラウザのタブごとに仮想マシン起動してそこで動かせばいいのに
仮想マシン上で、限定された権限のプロセスで、ブラウザエンジン動かせば、
たとえセキュリティホールがあっても、ダメージくらう確率は非常に少ないでしょう
Re: (スコア:0)
オーバーヘッドがそれなりに大きいのとブラウザのコードが肥大化するからでしょ。
Re: (スコア:0)
今でもあるよ。
Application Guardっていって、Hyper-Vをベースにしたコンテナ内でタブを開くことができるらしい。
使ったことはない。
Windows Defender Application Guard、他社ブラウザー用拡張を提供開始
https://security.srad.jp/story/19/03/20/2252223/ [security.srad.jp]
Re: (スコア:0)
HP Sure ClickとかMS以外からも似たソリューションは有る。
Re: (スコア:0)
コア分離したら、マウスもキーボードも動かなくなって、仕方なく電源ボタン長押しで強制終了した俺ガイル
Re: (スコア:0)
防火扉増やしますってのと、全面禁煙にして火災報知器を増やしますってのは別の話ですしおすし
Re: (スコア:0)
フェイトは犠牲になったのだ……ノーチラス号の犠牲にな……
Re: (スコア:0)
そういうのは仮想OS上のブラウザでも使えば十分では。
話は聞かせてもらったJITは速くない！ (スコア:0)
なんだってーΩΩΩ
これを期に不必要なJavaScriptの多用は減ってくれればありがたい (スコア:0)
ニュースサイトとか単に演出のためにJavaScript使ってて正直邪魔。
あと、お約束のように強制的な広告表示に悪用されてる現実もある。
Re: (スコア:0)
「これを期に」
Chrome OS という商品があるが文字通りだった (スコア:0)
ＯＳでかぶりそうな機能がありそうな仰々しい仕組みだな。それブラウザがやることか？ と直感してしまう技術だが、少し考え直した。もう昔ながらのカーネルスペース、ユーザースペース云々とかの概念は時代に合わないんだな。ウェブブラウザが安全にコードを動かすための基礎のすべてを提供するのがコンピューター端末の進化で起こる必然かもしれん。
Re: (スコア:0)
逆。仰々しい仕組みを捨ててブラウザ側はシンプルにしてあとはOSのセキュリティ機能に頼るって話
Re: (スコア:0)
OSに向いてることはOSがアプリが向いていることはアプリでって流れでは。
かつ多層防御化する。
Re: (スコア:0)
ごめんちょっと何言ってるか分かんない
Re: (スコア:0)
メモリ上のデータの暗号化を書くアプリでそれぞれ実装しろとでも？
Re: (スコア:0)
ああ、そのコメントを読んで(#4087335)を理解できた！
読点がなかったので日本語構文解析器がうまく文章をパースできなかったのだ
セキュリティを理由にしてFlashを排除したんだから (スコア:0)
脆弱性の半分がJIT起因だ、って言われたらJITを排除するのが公正というものだわな。
Re:セキュリティを理由にしてFlashを排除したんだから (スコア:1)
// なぜ誰も言わない
JIT無効化しても通常のブラウジングで体感できるような差は出ない (スコア:0)
ほんと？
Re: (スコア:0)
みんなが巨大Javascriptを作ってるけど
みんなで数種類の大Javascriptフレームワークを使い
みんなwebpack・難読化してるからリソースファイルとしては全部別
みたいな感じだから、グラフに整理したら（難読化除く）今のコンピューターリソースじゃほんと意味ないのかも
Re: (スコア:0)
もう１個。
JSはその言語仕様から非同期関数が発展することになったが、
非同期関数を呼ぶ関数は、最適化の有無は体感に寄与しないのが多そう。
Re: (スコア:0)
そりゃ、JavaScriptでゴリゴリ計算するのなんてブラウザゲーぐらいだろうし。
遅延要因として外部リソースのアクセス解析外す方がUXに影響しそう。
Re: (スコア:0)
ブラウザゲーってゴリゴリ計算してんの? サーバーからJSONか何かでもらった結果を描画しているだけだと思ってた
Re: (スコア:0)
Unityを使ったネイティブゲームはサーバーからJSONか何かでもらった結果を描画しているだけでしょうね
ブラウザゲーはよく知らないけどAjax(死語)でゴリゴリやってるんじゃないんですかね
Re: (スコア:0)
ゲーム以外ではビデオ・音声チャットなんかもJavaScriptあるいはWebAssemblyでごりごりやっているのではないかと思う。E2EEとかやろうとするとクライアント側で映像・音声に対する処理を入れるのでその辺り。