![Chrome Chrome](https://srad.jp/static/topics/chrome_64.png)
デスクトップ版Chrome 67、Spectreなどの対策としてSite Isolationが有効に 19
ストーリー by headless
対策 部門より
対策 部門より
デスクトップ版のChrome 67ではSpectre/Meltdownなどの脆弱性を狙う投機的実行のサイドチャネル攻撃を緩和するため、すべてのサイトを別プロセスで読み込む「Site Isolation」が有効になっているそうだ(Google Security Blogの記事、
Ars Technicaの記事、
The Registerの記事、
BetaNewsの記事)。
Chromeでは以前からタブごとに別のプロセスを使用しているが、タブ内のiframeやポップアップで別のサイトが読み込まれる場合はメインタブと同一プロセスが使われていたという。通常は同一オリジンポリシーによりクロスサイトiframeやポップアップの内容にメインドキュメントからアクセスすることはできないが、何らかの脆弱性を狙われた場合にはSpectreに限らず、Site Isolationが有効な緩和策となる。また、Webページがサブリソースとして読み込もうとするクロスサイトのHTML/XML/JSONレスポンスをブロックするCross-Origin Read Blocking(CORB)も含まれる。なお、同一ドメインのサブドメインについては同一サイト扱いになるとのこと。
Site IsolationはChrome 63 で実験的な企業向けのポリシーとして実装されており、多くの問題が解決されたことから、デスクトップ版Chromeの全ユーザーで有効にできるレベルに達したという。ただし、現時点で有効になっているのは99%のユーザーで、1%はパフォーマンス改善などのため無効のままにしているそうだ。プロセス増加により、メモリー使用量は10~13%程度の増加が見込まれる。
Site Isolationの動作はhttp://csreis.github.io/tests/cross-site-iframe.htmlを開いて「Go cross-site (complex page)」をクリックし、Chromeのメニューから「その他のツール→タスクマネージャ」を選んでタスクマネージャを起動すれば確かめられる。有効になっていればiframeに読み込まれたサイトが「サブフレーム」として表示されるはずだ。
Chromeでは以前からタブごとに別のプロセスを使用しているが、タブ内のiframeやポップアップで別のサイトが読み込まれる場合はメインタブと同一プロセスが使われていたという。通常は同一オリジンポリシーによりクロスサイトiframeやポップアップの内容にメインドキュメントからアクセスすることはできないが、何らかの脆弱性を狙われた場合にはSpectreに限らず、Site Isolationが有効な緩和策となる。また、Webページがサブリソースとして読み込もうとするクロスサイトのHTML/XML/JSONレスポンスをブロックするCross-Origin Read Blocking(CORB)も含まれる。なお、同一ドメインのサブドメインについては同一サイト扱いになるとのこと。
Site IsolationはChrome 63 で実験的な企業向けのポリシーとして実装されており、多くの問題が解決されたことから、デスクトップ版Chromeの全ユーザーで有効にできるレベルに達したという。ただし、現時点で有効になっているのは99%のユーザーで、1%はパフォーマンス改善などのため無効のままにしているそうだ。プロセス増加により、メモリー使用量は10~13%程度の増加が見込まれる。
Site Isolationの動作はhttp://csreis.github.io/tests/cross-site-iframe.htmlを開いて「Go cross-site (complex page)」をクリックし、Chromeのメニューから「その他のツール→タスクマネージャ」を選んでタスクマネージャを起動すれば確かめられる。有効になっていればiframeに読み込まれたサイトが「サブフレーム」として表示されるはずだ。
関係ない… (スコア:1)
別プロセスで動いていようが、影響があるから騒ぎになっていると思うんだけどなぁ。
いつからプロセスわけで十分という話になってしまったんだろう。
Re:関係ない… (スコア:2)
× 十分
○ 緩和
「いつから」もなにも、少なくともここでは「十分」とは言われてないようだが。
Re:関係ない… (スコア:1)
同じプロセスならサイドチェンネル攻撃に対して、ASLRが効かないからじゃないかな。
Re: (スコア:0)
WindowsのASLR実装って初回ロード時にランダム化したベースアドレスを使いまわすから別アドレスに配置されることを期待して同じEXE/DLLを使用してプロセス分けたって意味ないぜ
Re: (スコア:0)
別プロセスで動いていれば、別コアで動く可能性があるから、その場合は影響ないってことでは。
今回の脆弱性に対する完璧な対応は、性能の大幅低下を容認できない場合にはないようだから。
Re: (スコア:0)
Spectre に関しては同じアドレス空間で投機的実行をした場合にサンドボックスを突破される問題だと当初から言われてた印象がある。
https://support.google.com/faqs/answer/7622138 [google.com]
で案内された回避策の中に strict site isolation の設定 (chrome://flags/#enable-site-per-process) は当初からあった。当時は opt-in だったのがデフォルトで有効 (とはいえ A/B テストのため 1% くらいの環境では無効になってるっぽい) になったのでニュースになってる。
iframeやポップアップ (スコア:0)
これなくそーぜ、広告と攻撃にしか使ってねーからユーザーの利益なんてねーし
Re:iframeやポップアップ (スコア:3, 参考になる)
iframeを消して一番困るのが、GoogleのCAPTCHAを利用しているサイト。だから、userContent.cssを
にしてる。
あとは、
をブックマークに入れて、怪しいところで押す。
今迷っているのはTwitterの埋め込み引用。Twitterは利用者(=引用者=ウェブデザイナ)にはblockquoteを入れることを強要するんだけど、http://platform.twitter.com/widgets.jsというスクリプトで「そのblockquoteを消してiframeと入れ替える」っていう極悪なことをやってる(少なくともユーザーにはセマンティックを心がけるように強いておいて、自らは反セマンティックな改変を行っている)から、iframeを非表示にすると、最初は引用内容が見えているのに、ロードが完了すると消し去るという謎な動作をするようになる。このiframeにはURIがなくてその場で内容を作ってるから、[id^="twitter-widget-"]も例外にするか、tweetのIDからリンクを生成するかが悩みどころ。
Re:iframeやポップアップ (スコア:1)
この仕様は、http://platform.twitter.com/widgets.jsをブロックしている環境では非常にありがたいのです
つまり、ページ上はただのblockquoteなので、問題なく情報が表示できる(いや、もっと正確に言うとそこにTwitterのエンベッドがあることが認識できる)
エンベッド系でいちばん困るのは、サードパーティのスクリプトを読み込まないと表示さえされないもの
そこに埋め込み要素の存在自体がわからないというやつ
これに比べると、この仕様はよっぽどうれしいです
Re: (スコア:0)
これなくそーぜ、広告と攻撃にしか使ってねーからユーザーの利益なんてねーし
iframe分をCMSで定形書き出しにすればいいだけなので
なくしたところでなくらんよ
むしろクライアント側で排除悪くなるだけ
Re: (スコア:0)
なくすべきはPHP…いやHTMLだ!!
Re: (スコア:0)
これはWebサイトのセキュリティーホールではなく、CPUのセキュリティホールにまつわる話なわけで、そういう論調で話すならCPUを無くせでしょ。
Re: (スコア:0)
全然違う。少なくともターゲット広告をCMSでやるバカはいない。
Re: (スコア:0)
クッキー使ってますとか言ってくるのすげーうざい。
クッキーなんて最初からあるのになんで今更確認することになったの?
Re: (スコア:0)
GDPR対策で、Cookie使ってる事を通知してユーザーの了承を取った体にしておかないと、後で訴えられた時に不利になるからだったと思う。
Re: (スコア:0)
法律ができたんだから仕方ないでしょ、というのは説明になってないと思うけどな。
なんでそんなアホな法律を作ったのか、という疑問。
Re: (スコア:0)
法律が何か理解していますか?悪法だろうが何だろうが違反すればその法律で規定された処罰を受けることになるのですが。
クッキーの利用をユーザに通知するウェブサイトなんてGDPR策定以前からあったけど。
確かデルのウェブサイトはそうだった。
Re: (スコア:0)
欧州議会の議員を選んだ欧州諸国の国民一人ずつに聞いてこいよ
Re: (スコア:0)
つ https://yro.srad.jp/story/18/07/05/0735230/ [yro.srad.jp]