Site Isolationの話

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

Transcript

1. Site Isolationの話
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

11. Cross-Origin Read Blockingの背景
    クロスサイトなタブやフレームはSite Isolationでプロセスが隔離されるが、他のリ
    ソースはプロセスの隔離がされない
    例：
    
    imgタグで指定されたリソースをパースする為に、そのリソースをレンダラプロセス
    内のメモリにロードする必要がある
    ＝レンダラプロセスを掌握されると任意のサイトのレスポンスが読める
    

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View 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 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 Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

34. ブラウザ復元時の挙動を使ったバグ２
    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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide