パスワードを忘れた? アカウント作成
13647502 story
Chrome

デスクトップ版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に読み込まれたサイトが「サブフレーム」として表示されるはずだ。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by jizou (5538) on 2018年07月15日 16時36分 (#3443547) 日記

    別プロセスで動いていようが、影響があるから騒ぎになっていると思うんだけどなぁ。
    いつからプロセスわけで十分という話になってしまったんだろう。

    • by hjmhjm (39921) on 2018年07月16日 11時00分 (#3443724)

      × 十分
      ○ 緩和

      「いつから」もなにも、少なくともここでは「十分」とは言われてないようだが。

      親コメント
    • by shesee (27226) on 2018年07月16日 3時34分 (#3443673) 日記

      同じプロセスならサイドチェンネル攻撃に対して、ASLRが効かないからじゃないかな。

      親コメント
      • by Anonymous Coward

        WindowsのASLR実装って初回ロード時にランダム化したベースアドレスを使いまわすから別アドレスに配置されることを期待して同じEXE/DLLを使用してプロセス分けたって意味ないぜ

    • by Anonymous Coward

      別プロセスで動いていれば、別コアで動く可能性があるから、その場合は影響ないってことでは。
      今回の脆弱性に対する完璧な対応は、性能の大幅低下を容認できない場合にはないようだから。

    • by Anonymous Coward

      Spectre に関しては同じアドレス空間で投機的実行をした場合にサンドボックスを突破される問題だと当初から言われてた印象がある。
      https://support.google.com/faqs/answer/7622138 [google.com]
      で案内された回避策の中に strict site isolation の設定 (chrome://flags/#enable-site-per-process) は当初からあった。当時は opt-in だったのがデフォルトで有効 (とはいえ A/B テストのため 1% くらいの環境では無効になってるっぽい) になったのでニュースになってる。

  • by Anonymous Coward on 2018年07月15日 12時50分 (#3443504)

    これなくそーぜ、広告と攻撃にしか使ってねーからユーザーの利益なんてねーし

    • by Anonymous Coward on 2018年07月15日 14時10分 (#3443521)

      iframeを消して一番困るのが、GoogleのCAPTCHAを利用しているサイト。だから、userContent.cssを

      iframe {
        display: none !important;
      }
       
      iframe[src^="https://www.google.com/recaptcha"] {
        display: inline-block !important;
      }

      にしてる。

      あとは、

      javascript:(
        function (){
          let frames = document.getElementsByTagName("iframe");
          for (let i = 0; i < frames.length; i++) {
            let frame = frames[i];
            if (!frame.src)
              continue;
            let paragraph = document.createElement("p");
            let anchor = document.createElement("a");
            anchor.href = frame.src;
            anchor.textContent = frame.src;
            anchor.target = "_blank";
            paragraph.appendChild(anchor);
            frame.parentNode.insertBefore(paragraph, frame.nextSibling);
          }
        })();

      をブックマークに入れて、怪しいところで押す。

      今迷っているのはTwitterの埋め込み引用。Twitterは利用者(=引用者=ウェブデザイナ)にはblockquoteを入れることを強要するんだけど、http://platform.twitter.com/widgets.jsというスクリプトで「そのblockquoteを消してiframeと入れ替える」っていう極悪なことをやってる(少なくともユーザーにはセマンティックを心がけるように強いておいて、自らは反セマンティックな改変を行っている)から、iframeを非表示にすると、最初は引用内容が見えているのに、ロードが完了すると消し去るという謎な動作をするようになる。このiframeにはURIがなくてその場で内容を作ってるから、[id^="twitter-widget-"]も例外にするか、tweetのIDからリンクを生成するかが悩みどころ。

      親コメント
      • by Anonymous Coward on 2018年07月17日 13時10分 (#3444078)

        http://platform.twitter.com/widgets.js [twitter.com]というスクリプトで「そのblockquoteを消してiframeと入れ替える」っていう極悪なことをやってる(少なくともユーザーにはセマンティックを心がけるように強いておいて、自らは反セマンティックな改変を行っている

        この仕様は、http://platform.twitter.com/widgets.jsをブロックしている環境では非常にありがたいのです
        つまり、ページ上はただのblockquoteなので、問題なく情報が表示できる(いや、もっと正確に言うとそこにTwitterのエンベッドがあることが認識できる)

        エンベッド系でいちばん困るのは、サードパーティのスクリプトを読み込まないと表示さえされないもの
        そこに埋め込み要素の存在自体がわからないというやつ

        これに比べると、この仕様はよっぽどうれしいです

        親コメント
    • by Anonymous Coward

      これなくそーぜ、広告と攻撃にしか使ってねーからユーザーの利益なんてねーし

      iframe分をCMSで定形書き出しにすればいいだけなので
      なくしたところでなくらんよ
      むしろクライアント側で排除悪くなるだけ

      • by Anonymous Coward

        なくすべきはPHP…いやHTMLだ!!

        • by Anonymous Coward

          これはWebサイトのセキュリティーホールではなく、CPUのセキュリティホールにまつわる話なわけで、そういう論調で話すならCPUを無くせでしょ。

      • by Anonymous Coward

        全然違う。少なくともターゲット広告をCMSでやるバカはいない。

    • by Anonymous Coward

      クッキー使ってますとか言ってくるのすげーうざい。
      クッキーなんて最初からあるのになんで今更確認することになったの?

      • by Anonymous Coward

        GDPR対策で、Cookie使ってる事を通知してユーザーの了承を取った体にしておかないと、後で訴えられた時に不利になるからだったと思う。

        • by Anonymous Coward

          法律ができたんだから仕方ないでしょ、というのは説明になってないと思うけどな。
          なんでそんなアホな法律を作ったのか、という疑問。

          • by Anonymous Coward

            法律が何か理解していますか?悪法だろうが何だろうが違反すればその法律で規定された処罰を受けることになるのですが。
            クッキーの利用をユーザに通知するウェブサイトなんてGDPR策定以前からあったけど。
            確かデルのウェブサイトはそうだった。

          • by Anonymous Coward

            欧州議会の議員を選んだ欧州諸国の国民一人ずつに聞いてこいよ

      • by Anonymous Coward
typodupeerror

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

読み込み中...