デスクトップ版Chrome 67、Spectreなどの対策としてSite Isolationが有効に 16
ストーリー 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)
別プロセスで動いていれば、別コアで動く可能性があるから、その場合は影響ないってことでは。
今回の脆弱性に対する完璧な対応は、性能の大幅低下を容認できない場合にはないようだから。
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: (スコア: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)
つ https://yro.srad.jp/story/18/07/05/0735230/ [yro.srad.jp]
Re: (スコア:0)
iframeを消して一番困るのが、GoogleのCAPTCHAを利用しているサイト。だから、userContent.cssを
にしてる。
あとは、