Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Site Isolationの話

Site Isolationの話

Shibuya.XSS techtalk #11で話したスライド
Site Isolation、Cross-Origin Read Blocking、Spectreなどなど

Jun Kokatsu

May 16, 2019
Tweet

More Decks by Jun Kokatsu

Other Decks in Research

Transcript

  1. Site Isolationの話

    View full-size slide

  2. 職務質問
    Q: お名前は?
    A: 小勝純です
    Q: SNS教えなさい
    A: @shhnjkです
    Q: お仕事は?
    A: マイクロソフトでBrowser Vulnerability Researchチームに所属してます
    Q: ビザ見せなさい
    A: 日本人です

    View full-size slide

  3. Agenda
    1. Site Isolationについて
    2. Cross-Origin Read Blockingについて
    3. Spectreについて
    4. 見つけたバグの話
    5. まとめ

    View full-size slide

  4. Chromeのプロセスモデル
    ブラウザプロセス:
    Chromeのプロセスの中で一番権限が高いプロセス。サンドボックス外の
    プロセスで、各レンダラプロセスの管理やリソースの供給、権限の授与を担当

    View full-size slide

  5. Chromeのプロセスモデル
    ブラウザプロセス:
    Chromeのプロセスの中で一番権限が高いプロセス。サンドボックス外の
    プロセスで、各レンダラプロセスの管理やリソースの供給、権限の授与を担当
    レンダラプロセス:
    Chromeのプロセスの中で一番権限が低い、サンドボックスされたプロセス。ウェブ
    ページをレンダリングしたり、JSを実行したりする

    View full-size slide

  6. Site Isolationの背景
    ● オンライン上のデータの重要度が日に日に増している

    View full-size slide

  7. Site Isolationの背景
    ● オンライン上のデータの重要度が日に日に増している
    ● ブラウザのサンドボックスをエスケープしなくてもレンダラプロセスを掌握出来
    ればUXSSなどが可能だった

    View full-size slide

  8. Site Isolationの背景
    ● オンライン上のデータの重要度が日に日に増している
    ● ブラウザのサンドボックスをエスケープしなくてもレンダラプロセスを掌握出来
    ればUXSSなどが可能だった
    ● 今後の攻撃がサンドボックスをエスケープするものから他サイトへのアクセス
    を悪用するものに推移するのではないか

    View full-size slide

  9. Site Isolationとは
    サイトごとにレンダラプロセスを隔離する
    Chromeのセキュリティ機能
    Siteとは:
    Scheme と eTLD+1
    https://www.example.com:443
    https://www.chromium.org/developers/design-documents/site-isolation

    View full-size slide

  10. Cross-Origin Read Blockingの背景
    クロスサイトなタブやフレームはSite Isolationでプロセスが隔離されるが、他のリ
    ソースはプロセスの隔離がされない
    例:

    View full-size slide

  11. Cross-Origin Read Blockingの背景
    クロスサイトなタブやフレームはSite Isolationでプロセスが隔離されるが、他のリ
    ソースはプロセスの隔離がされない
    例:

    imgタグで指定されたリソースをパースする為に、そのリソースをレンダラプロセス
    内のメモリにロードする必要がある
    =レンダラプロセスを掌握されると任意のサイトのレスポンスが読める

    View full-size slide

  12. Cross-Origin Read Blockingとは
    HTMLかXMLかJSONのContent-Typeを持つリソースがクロスオリジンな
    プロセスにロードされないようにするセキュリティ機能
    X-Content-Type-Options: nosniffが指定されていない場合はコンテンツを
    スニフする
    Renderer:
    https://evil.tld

    Browser process victim.tld
    Content-Type: text/html
    X-Content-Type-Options: nosniff

    View full-size slide

  13. Spectre
    ● サイドチャネル攻撃を使うことで別プロセスのデータを読み取れる
    CPUの脆弱性

    View full-size slide

  14. Spectre
    ● サイドチャネル攻撃を使うことで別プロセスのデータを読み取れる
    CPUの脆弱性
    ● OSレベルのパッチにより、今まで通り
    OSプロセスの隔離は保証されるが、同
    一プロセス内に機密データと信頼出来ないコードが共存する場合は未だにサ
    イドチャネル攻撃が可能

    View full-size slide

  15. Spectre
    ● サイドチャネル攻撃を使うことで別プロセスのデータを読み取れる
    CPUの脆弱性
    ● OSレベルのパッチにより、今まで通り
    OSプロセスの隔離は保証されるが、同
    一プロセス内に機密データと信頼出来ないコードが共存する場合は未だにサ
    イドチャネル攻撃が可能
    ● 脆弱性無しでもJavascriptを使うと同一プロセス内の全てのデータを
    読めてしまう

    View full-size slide

  16. ChromeによるSpectreの緩和策
    performance.now()の精度削減、SharedArrayBufferの無効化、投機的実行時の
    メモリマスクなど
    >これらは総合的で効率的な緩和策ではない
    詳細:https://v8.dev/blog/spectre

    View full-size slide

  17. ChromeによるSpectreの緩和策
    performance.now()の精度削減、SharedArrayBufferの無効化、投機的実行時の
    メモリマスクなど
    >これらは総合的で効率的な緩和策ではない
    詳細:https://v8.dev/blog/spectre
    OSレベルでの隔離が保証されるSite Isolationが一番効果的なSpectre対策

    View full-size slide

  18. Spectre対策としてのSite Isolation
    当時完成していなかったSite Isolationを効果的なSpectre対策とする為に、新たな
    脅威モデルによるSite IsolationがChrome 67から有効にされた
    1. クロスサイトなタブやフレームには別プロセスを振り分ける
    2. CORBを有効にする

    View full-size slide

  19. Spectre対策としてのSite Isolation
    当時完成していなかったSite Isolationを効果的なSpectre対策とする為に、新たな
    脅威モデルによるSite IsolationがChrome 67から有効にされた
    1. クロスサイトなタブやフレームには別プロセスを振り分ける
    2. CORBを有効にする
    しかし、レンダラプロセス内のデータが改ざんされてブラウザプロセスを騙す様な当
    初のSite Isolationが想定していた脅威モデルには対応せず

    View full-size slide

  20. Spectre対策としてのSite Isolation
    当時完成していなかったSite Isolationを効果的なSpectre対策とする為に、新たな
    脅威モデルによるSite IsolationがChrome 67から有効にされた
    1. クロスサイトなタブやフレームには別プロセスを振り分ける
    2. CORBを有効にする
    しかし、レンダラプロセス内のデータが改ざんされてブラウザプロセスを騙す様な当
    初のSite Isolationが想定していた脅威モデルには対応せず
    レンダラプロセス内のデータを改ざんせずに上記2つのどちらかをバイパス出来れ
    ば報奨金が貰える!

    View full-size slide

  21. クロスサイトを突き詰める
    URLのHostがドメイン名ではない場合、SchemeとHostが完全一致した場合のみ
    同一サイトと判断される
    例:http://204.79.197.200/

    View full-size slide

  22. クロスサイトを突き詰める
    URLのHostがドメイン名ではない場合、SchemeとHostが完全一致した場合のみ
    同一サイトと判断される
    例:http://204.79.197.200/
    Blob URLやFileSystem URLなどオリジンがURL内にあるものは、そのオリジンを
    元に同一サイトかを比較する
    例:blob:https://www.bing.com/ed14d1bc-2fdc-4408-82ed-37c06ba1eab5

    View full-size slide

  23. クロスサイトを突き詰める
    URLのHostがドメイン名ではない場合、SchemeとHostが完全一致した場合のみ
    同一サイトと判断される
    例:http://204.79.197.200/
    Blob URLやFileSystem URLなどオリジンがURL内にあるものは、そのオリジンを
    元に同一サイトかを比較する
    例:blob:https://www.bing.com/ed14d1bc-2fdc-4408-82ed-37c06ba1eab5
    一つ目のバグが分かりましたか?

    View full-size slide

  24. Blob URLのオリジン
    CSP/iframeサンドボックスもしくはData URLから作られたBlob URLは以下の様に
    なる
    blob:null/06a61233-03ba-4ebe-a0ad-5b5c71e56bd0
    SchemeとHostが完全に一致しているので常に同一サイトとみなされる

    View full-size slide

  25. Blob URLのオリジン
    CSP/iframeサンドボックスもしくはData URLから作られたBlob URLは以下の様に
    なる
    blob:null/06a61233-03ba-4ebe-a0ad-5b5c71e56bd0
    SchemeとHostが完全に一致しているので常に同一サイトとみなされる
    結果、クロスサイトなはずの2つの
    Blob URLが同一プロセス内にレンダリングされ
    てしまう
    CVE-2018-16074: $3000

    View full-size slide

  26. Data URLの扱い
    Data URLがiframe内で表示された場合、ナビゲーションを開始したサイトと
    Data
    URLは同一サイトとみなされる
    https://example.tld

    同一サイト
    https://example.tld
    https://evil.tld
    <br/>location.href=”data:,test”;<br/>
    クロスサイト

    View full-size slide

  27. ブラウザ復元時の挙動
    https://victim.tld
    https://evil.tld
    <br/>location.href=”data:,test”;<br/>
    https://evil.tldからData URLがロードされた後
    にブラウザプロセスをクラッシュする
    例:https://crbug.com/935050

    View full-size slide

  28. ブラウザ復元時の挙動
    https://victim.tld
    https://evil.tld
    <br/>location.href=”data:,test”;<br/>
    https://evil.tldからData URLがロードされた後
    にブラウザプロセスをクラッシュする
    例:https://crbug.com/935050

    View full-size slide

  29. ブラウザ復元時の挙動
    https://victim.tld
    https://evil.tld
    <br/>location.href=”data:,test”;<br/>
    https://evil.tldからData URLがロードされた後
    にブラウザプロセスをクラッシュする
    例:https://crbug.com/935050

    https://victim.tld
    data:,test
    ローカルキャッシュから復元される際にクロスサイトな
    Data
    URLが同一サイトとみなされてしまう
    CVE-2018-16073: $3000

    View full-size slide

  30. 修正後
    ブラウザまたはタブ復元後のData URLはどのサイトに属しているかがわからない
    為、復元後はフラグメントを抜いた
    Data URL自体をサイトとして扱う様になった

    View full-size slide

  31. 修正後
    ブラウザまたはタブ復元後のData URLはどのサイトに属しているかがわからない
    為、復元後はフラグメントを抜いた
    Data URL自体をサイトとして扱う様になった
    しかしChromeにはData URLのフラグメント以降もData URLのボディとして扱う挙
    動があった
    data:text/html,body#this is body too

    View full-size slide

  32. ブラウザ復元時の挙動を使ったバグ2
    https://evil.tld
    data:text/html,
    <br/>alert(1);<br/>
    https://victim.tld
    data:text/html,

    secret

    View full-size slide

  33. ブラウザ復元時の挙動を使ったバグ2
    https://evil.tld
    data:text/html,
    <br/>alert(1);<br/>
    https://victim.tld
    data:text/html,

    secret

    クラッシュ

    View full-size slide

  34. ブラウザ復元時の挙動を使ったバグ2
    https://evil.tld
    data:text/html,
    <br/>alert(1);<br/>
    https://victim.tld
    data:text/html,

    secret

    https://evil.tld
    data:text/html,
    <br/>alert(1);<br/>
    https://victim.tld
    data:text/html,

    secret

    クラッシュ
    同一サイト
    $500
    https://www.chromestatus.com/feature/5656
    049583390720

    View full-size slide

  35. CORBをバイパスしてみる
    Application CacheはクロスオリジンのリソースをCORS無しで明示的にキャッシュ
    することが出来る
    CACHE MANIFEST
    CACHE:
    https://www.google.com

    View full-size slide

  36. CORBをバイパスしてみる
    Application CacheはクロスオリジンのリソースをCORS無しで明示的にキャッシュ
    することが出来る
    CACHE MANIFEST
    CACHE:
    https://www.google.com
    ブラウザがこのキャッシュを行う際
    CORBのチェックを怠っていた為、
    明示的にキャッシュしたリソースを使うことによって
    CORBがバイパス
    出来た
    Chrome Securityチームが先に見つけていたので重複

    View full-size slide

  37. レンダラプロセスを信頼しないSite Isolationへ
    当初の目標であったレンダラプロセスを一切信頼しない脅威モデルの確立に向け
    て着々と実装が行われている
    ● Out-of-Renderer CORS
    ● 各IPCの再チェック
    ● 現状の実装で実際のサイトが守れるかの確認
    などなど

    View full-size slide

  38. レンダラプロセスを信頼しないSite Isolationへ
    当初の目標であったレンダラプロセスを一切信頼しない脅威モデルの確立に向け
    て着々と実装が行われている
    ● Out-of-Renderer CORS
    ● 各IPCの再チェック
    ● 現状の実装で実際のサイトが守れるかの確認
    などなど
    こちらも実際に見つかったバグを紹介します
    ※まだ実装が完璧ではない為、セキュリティのバグではなくセキュリティ機能の向上 として
    扱われる場合があります

    View full-size slide

  39. Blob URLを使ったUXSS
    キヌガワさんが見つけたバグ!
    Blob URLを作る際、レンダラプロセス内のオリジンを偽
    装することでブラウザプロセスを騙して別オリジンの
    Blob URLを作ることが出来る
    Blob URLのコンテンツも自由に指定出来るので
    UXSS
    となる
    CVE-2018-18345: $8000
    Browser Process
    Renderer Process
    https://evil.tld
    I need a Blob URL
    for Google.com!
    Sure!

    View full-size slide

  40. ナビゲーションコミット時のオリジン偽装
    Chromeにはナビゲーションが開始された後にレスポンスをロードする為のレンダ
    ラプロセスからナビゲーションをコミットするという概念がある
    Life of a Navigation:https://youtu.be/mX7jQsGCF6E
    Navigate to
    https://evil.tld
    Commit navigation
    with https://victim.tld

    View full-size slide

  41. UXSSに昇格
    別オリジンにコミット出来ることは
    Chromeチームが知っていたので重複
    レンダラプロセス自体は攻撃者のサイト用のままのなので
    UXSSが出来ない

    View full-size slide

  42. UXSSに昇格
    別オリジンにコミット出来ることは
    Chromeチームが知っていたので重複
    レンダラプロセス自体は攻撃者のサイト用のままのなので
    UXSSが出来ない
    レンダラプロセスがアクセス出来るオリジンを確認されてしまう
    APIには
    オリジンの偽装がバレるが、そうでない
    APIは上手く騙せていた
    Service Workerを使うサイトに対してはCache APIを使ってUXSSが出来た
    https://crbug.com/915396

    View full-size slide

  43. postMessageのオリジン偽装
    レンダラプロセス内のオリジンを偽装した後に
    postMessageすると
    メッセージを受け取った側に偽装されたオリジンが送られてしまう
    https://evil.tld
    https://victim.tld
    frames[0].postMessage(“hello”,”*”);
    alert(event.origin)// https://victim.tld
    $3000
    https://crbug.com/915398

    View full-size slide

  44. 気をつけて欲しいこと
    開発者へ
    ● 信頼出来ないData URLをiframeで表示することはXSSではないが危険

    View full-size slide

  45. 気をつけて欲しいこと
    開発者へ
    ● 信頼出来ないData URLをiframeで表示することはXSSではないが危険
    ● HTML、XML、JSON以外の機密ファイルでクロスサイトに読み込まれる必要
    がないものにはCORPヘッダーを設定しよう!

    View full-size slide

  46. 気をつけて欲しいこと
    開発者へ
    ● 信頼出来ないData URLをiframeで表示することはXSSではないが危険
    ● HTML、XML、JSON以外の機密ファイルでクロスサイトに読み込まれる必要
    がないものにはCORPヘッダーを設定しよう!
    ● https://www.chromium.org/Home/chromium-security/corb-for-developers

    View full-size slide

  47. 気をつけて欲しいこと
    開発者へ
    ● 信頼出来ないData URLをiframeで表示することはXSSではないが危険
    ● HTML、XML、JSON以外の機密ファイルでクロスサイトに読み込まれる必要
    がないものにはCORPヘッダーを設定しよう!
    ● https://www.chromium.org/Home/chromium-security/corb-for-developers
    ユーザへ
    ● 信頼出来ないローカルファイルは開かないようにしよう!
    (現状全てのFile URLは同一サイト)

    View full-size slide

  48. Site Isolationで変わってきたこと
    ● レンダラプロセスを掌握してもUXSSをする為には更にバグが必要になった

    View full-size slide

  49. Site Isolationで変わってきたこと
    ● レンダラプロセスを掌握してもUXSSをする為には更にバグが必要になった
    ● ブラウザプロセスのアタックサーフェイスが増加した

    View full-size slide

  50. Site Isolationで変わってきたこと
    ● レンダラプロセスを掌握してもUXSSをする為には更にバグが必要になった
    ● ブラウザプロセスのアタックサーフェイスが増加した
    ● ブラウザのバグがサイトの設定で防げるようになってきた

    View full-size slide

  51. Site Isolationで変わってきたこと
    ● レンダラプロセスを掌握してもUXSSをする為には更にバグが必要になった
    ● ブラウザプロセスのアタックサーフェイスが増加した
    ● ブラウザのバグがサイトの設定で防げるようになってきた
    ● SOPバイパスがSite Isolation関連で守られていない所に集中し始めた

    View full-size slide

  52. Site Isolationで変わってきたこと
    ● レンダラプロセスを掌握してもUXSSをする為には更にバグが必要になった
    ● ブラウザプロセスのアタックサーフェイスが増加した
    ● ブラウザのバグがサイトの設定で防げるようになってきた
    ● SOPバイパスがSite Isolation関連で守られていない所に集中し始めた
    ● Siteという概念がより強くなり始めた

    View full-size slide

  53. Site Isolationをテストしたい方へ
    Spoof.js
    https://github.com/shhnjk/spoof.js
    Chromeのレンダラプロセス内のオリジンと
    URLを偽装してくれる
    WinDbgの拡張スクリプト
    オリジンとURLを偽装した後に任意のAPIを呼ぶことでそのAPIが偽装したオリジン
    やURLに騙されないか試せる

    View full-size slide

  54. Questions?
    Acknowledgement:
    Thanks Chrome Site Isolation team!
    (nasko, lukasza, creis, and others)

    View full-size slide