Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Site Isolationの話
Search
Jun Kokatsu
May 16, 2019
Research
5
1.8k
Site Isolationの話
Shibuya.XSS techtalk #11で話したスライド
Site Isolation、Cross-Origin Read Blocking、Spectreなどなど
Jun Kokatsu
May 16, 2019
Tweet
Share
More Decks by Jun Kokatsu
See All by Jun Kokatsu
Piloting Edge Copilot
shhnjk
1
530
Same-Origin Cross-Context Scripting
shhnjk
0
820
The world of Site Isolation and compromised renderer
shhnjk
1
2.6k
ブラウザセキュリティ機能は バイパスされる為にある
shhnjk
8
3.7k
Logically Bypassing Browser Security Boundaries
shhnjk
5
3.1k
Other Decks in Research
See All in Research
Geospecific View Generation - Geometry-Context Aware High-resolution Ground View Inference from Satellite Views
satai
1
100
Isotropy, Clusters, and Classifiers
hpprc
3
630
外積やロドリゲスの回転公式を利用した点群の回転
kentaitakura
1
650
[ECCV2024読み会] 衛星画像からの地上画像生成
elith
1
680
システムから変える 自分と世界を変えるシステムチェンジの方法論 / Systems Change Approaches
dmattsun
3
860
MIRU2024_招待講演_RALF_in_CVPR2024
udonda
1
330
渋谷Well-beingアンケート調査結果
shibuyasmartcityassociation
0
260
[2024.08.30] Gemma-Ko, 오픈 언어모델에 한국어 입히기 @ 머신러닝부트캠프2024
beomi
0
720
MIRU2024チュートリアル「様々なセンサやモダリティを用いたシーン状態推定」
miso2024
4
2.2k
Introducing Research Units of Matsuo-Iwasawa Laboratory
matsuolab
0
920
Weekly AI Agents News! 8月号 論文のアーカイブ
masatoto
1
180
新規のC言語処理系を実装することによる 組込みシステム研究にもたらす価値 についての考察
zacky1972
0
140
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2.1k
Art, The Web, and Tiny UX
lynnandtonic
297
20k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
130
Scaling GitHub
holman
458
140k
We Have a Design System, Now What?
morganepeng
50
7.2k
KATA
mclloyd
29
14k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
370
The Pragmatic Product Professional
lauravandoore
31
6.3k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Keith and Marios Guide to Fast Websites
keithpitt
409
22k
Transcript
Site Isolationの話
職務質問 Q: お名前は? A: 小勝純です Q: SNS教えなさい A: @shhnjkです Q:
お仕事は? A: マイクロソフトでBrowser Vulnerability Researchチームに所属してます Q: ビザ見せなさい A: 日本人です
Agenda 1. Site Isolationについて 2. Cross-Origin Read Blockingについて 3. Spectreについて
4. 見つけたバグの話 5. まとめ
Chromeのプロセスモデル ブラウザプロセス: Chromeのプロセスの中で一番権限が高いプロセス。サンドボックス外の プロセスで、各レンダラプロセスの管理やリソースの供給、権限の授与を担当
Chromeのプロセスモデル ブラウザプロセス: Chromeのプロセスの中で一番権限が高いプロセス。サンドボックス外の プロセスで、各レンダラプロセスの管理やリソースの供給、権限の授与を担当 レンダラプロセス: Chromeのプロセスの中で一番権限が低い、サンドボックスされたプロセス。ウェブ ページをレンダリングしたり、JSを実行したりする
Site Isolationの背景 • オンライン上のデータの重要度が日に日に増している
Site Isolationの背景 • オンライン上のデータの重要度が日に日に増している • ブラウザのサンドボックスをエスケープしなくてもレンダラプロセスを掌握出来 ればUXSSなどが可能だった
Site Isolationの背景 • オンライン上のデータの重要度が日に日に増している • ブラウザのサンドボックスをエスケープしなくてもレンダラプロセスを掌握出来 ればUXSSなどが可能だった • 今後の攻撃がサンドボックスをエスケープするものから他サイトへのアクセス を悪用するものに推移するのではないか
Site Isolationとは サイトごとにレンダラプロセスを隔離する Chromeのセキュリティ機能 Siteとは: Scheme と eTLD+1 https://www.example.com:443 https://www.chromium.org/developers/design-documents/site-isolation
Cross-Origin Read Blockingの背景 クロスサイトなタブやフレームはSite Isolationでプロセスが隔離されるが、他のリ ソースはプロセスの隔離がされない 例: <img src=”https://www.google.com”>
Cross-Origin Read Blockingの背景 クロスサイトなタブやフレームはSite Isolationでプロセスが隔離されるが、他のリ ソースはプロセスの隔離がされない 例: <img src=”https://www.google.com”> imgタグで指定されたリソースをパースする為に、そのリソースをレンダラプロセス
内のメモリにロードする必要がある =レンダラプロセスを掌握されると任意のサイトのレスポンスが読める
Cross-Origin Read Blockingとは HTMLかXMLかJSONのContent-Typeを持つリソースがクロスオリジンな プロセスにロードされないようにするセキュリティ機能 X-Content-Type-Options: nosniffが指定されていない場合はコンテンツを スニフする Renderer: https://evil.tld
<img src=”//victim.tld”> Browser process victim.tld Content-Type: text/html X-Content-Type-Options: nosniff
Spectre • サイドチャネル攻撃を使うことで別プロセスのデータを読み取れる CPUの脆弱性
Spectre • サイドチャネル攻撃を使うことで別プロセスのデータを読み取れる CPUの脆弱性 • OSレベルのパッチにより、今まで通り OSプロセスの隔離は保証されるが、同 一プロセス内に機密データと信頼出来ないコードが共存する場合は未だにサ イドチャネル攻撃が可能
Spectre • サイドチャネル攻撃を使うことで別プロセスのデータを読み取れる CPUの脆弱性 • OSレベルのパッチにより、今まで通り OSプロセスの隔離は保証されるが、同 一プロセス内に機密データと信頼出来ないコードが共存する場合は未だにサ イドチャネル攻撃が可能 •
脆弱性無しでもJavascriptを使うと同一プロセス内の全てのデータを 読めてしまう
ChromeによるSpectreの緩和策 performance.now()の精度削減、SharedArrayBufferの無効化、投機的実行時の メモリマスクなど >これらは総合的で効率的な緩和策ではない 詳細:https://v8.dev/blog/spectre
ChromeによるSpectreの緩和策 performance.now()の精度削減、SharedArrayBufferの無効化、投機的実行時の メモリマスクなど >これらは総合的で効率的な緩和策ではない 詳細:https://v8.dev/blog/spectre OSレベルでの隔離が保証されるSite Isolationが一番効果的なSpectre対策
Spectre対策としてのSite Isolation 当時完成していなかったSite Isolationを効果的なSpectre対策とする為に、新たな 脅威モデルによるSite IsolationがChrome 67から有効にされた 1. クロスサイトなタブやフレームには別プロセスを振り分ける 2.
CORBを有効にする
Spectre対策としてのSite Isolation 当時完成していなかったSite Isolationを効果的なSpectre対策とする為に、新たな 脅威モデルによるSite IsolationがChrome 67から有効にされた 1. クロスサイトなタブやフレームには別プロセスを振り分ける 2.
CORBを有効にする しかし、レンダラプロセス内のデータが改ざんされてブラウザプロセスを騙す様な当 初のSite Isolationが想定していた脅威モデルには対応せず
Spectre対策としてのSite Isolation 当時完成していなかったSite Isolationを効果的なSpectre対策とする為に、新たな 脅威モデルによるSite IsolationがChrome 67から有効にされた 1. クロスサイトなタブやフレームには別プロセスを振り分ける 2.
CORBを有効にする しかし、レンダラプロセス内のデータが改ざんされてブラウザプロセスを騙す様な当 初のSite Isolationが想定していた脅威モデルには対応せず レンダラプロセス内のデータを改ざんせずに上記2つのどちらかをバイパス出来れ ば報奨金が貰える!
クロスサイトを突き詰める URLのHostがドメイン名ではない場合、SchemeとHostが完全一致した場合のみ 同一サイトと判断される 例:http://204.79.197.200/
クロスサイトを突き詰める URLのHostがドメイン名ではない場合、SchemeとHostが完全一致した場合のみ 同一サイトと判断される 例:http://204.79.197.200/ Blob URLやFileSystem URLなどオリジンがURL内にあるものは、そのオリジンを 元に同一サイトかを比較する 例:blob:https://www.bing.com/ed14d1bc-2fdc-4408-82ed-37c06ba1eab5
クロスサイトを突き詰める URLのHostがドメイン名ではない場合、SchemeとHostが完全一致した場合のみ 同一サイトと判断される 例:http://204.79.197.200/ Blob URLやFileSystem URLなどオリジンがURL内にあるものは、そのオリジンを 元に同一サイトかを比較する 例:blob:https://www.bing.com/ed14d1bc-2fdc-4408-82ed-37c06ba1eab5 一つ目のバグが分かりましたか?
Blob URLのオリジン CSP/iframeサンドボックスもしくはData URLから作られたBlob URLは以下の様に なる blob:null/06a61233-03ba-4ebe-a0ad-5b5c71e56bd0 SchemeとHostが完全に一致しているので常に同一サイトとみなされる
Blob URLのオリジン CSP/iframeサンドボックスもしくはData URLから作られたBlob URLは以下の様に なる blob:null/06a61233-03ba-4ebe-a0ad-5b5c71e56bd0 SchemeとHostが完全に一致しているので常に同一サイトとみなされる 結果、クロスサイトなはずの2つの Blob
URLが同一プロセス内にレンダリングされ てしまう CVE-2018-16074: $3000
Data URLの扱い Data URLがiframe内で表示された場合、ナビゲーションを開始したサイトと Data URLは同一サイトとみなされる https://example.tld <iframe src=”data:,test”> 同一サイト
https://example.tld https://evil.tld <script> location.href=”data:,test”; </script> クロスサイト
ブラウザ復元時の挙動 https://victim.tld https://evil.tld <script> location.href=”data:,test”; </script> https://evil.tldからData URLがロードされた後 にブラウザプロセスをクラッシュする 例:https://crbug.com/935050
<iframe src=”data:application/signed-exchange,”>
ブラウザ復元時の挙動 https://victim.tld https://evil.tld <script> location.href=”data:,test”; </script> https://evil.tldからData URLがロードされた後 にブラウザプロセスをクラッシュする 例:https://crbug.com/935050
<iframe src=”data:application/signed-exchange,”>
ブラウザ復元時の挙動 https://victim.tld https://evil.tld <script> location.href=”data:,test”; </script> https://evil.tldからData URLがロードされた後 にブラウザプロセスをクラッシュする 例:https://crbug.com/935050
<iframe src=”data:application/signed-exchange,”> https://victim.tld data:,test ローカルキャッシュから復元される際にクロスサイトな Data URLが同一サイトとみなされてしまう CVE-2018-16073: $3000
修正後 ブラウザまたはタブ復元後のData URLはどのサイトに属しているかがわからない 為、復元後はフラグメントを抜いた Data URL自体をサイトとして扱う様になった
修正後 ブラウザまたはタブ復元後のData URLはどのサイトに属しているかがわからない 為、復元後はフラグメントを抜いた Data URL自体をサイトとして扱う様になった しかしChromeにはData URLのフラグメント以降もData URLのボディとして扱う挙 動があった
data:text/html,<b>body</b>#<s>this is body too</s>
ブラウザ復元時の挙動を使ったバグ2 https://evil.tld data:text/html, <body bgcolor="#"><script> alert(1); </script></body> https://victim.tld data:text/html, <body
bgcolor="#E6E6FA"> secret </body>
ブラウザ復元時の挙動を使ったバグ2 https://evil.tld data:text/html, <body bgcolor="#"><script> alert(1); </script></body> https://victim.tld data:text/html, <body
bgcolor="#E6E6FA"> secret </body> クラッシュ
ブラウザ復元時の挙動を使ったバグ2 https://evil.tld data:text/html, <body bgcolor="#"><script> alert(1); </script></body> https://victim.tld data:text/html, <body
bgcolor="#E6E6FA"> secret </body> https://evil.tld data:text/html, <body bgcolor="#"><script> alert(1); </script></body> https://victim.tld data:text/html, <body bgcolor="#E6E6FA"> secret </body> クラッシュ 同一サイト $500 https://www.chromestatus.com/feature/5656 049583390720
CORBをバイパスしてみる Application CacheはクロスオリジンのリソースをCORS無しで明示的にキャッシュ することが出来る CACHE MANIFEST CACHE: https://www.google.com
CORBをバイパスしてみる Application CacheはクロスオリジンのリソースをCORS無しで明示的にキャッシュ することが出来る CACHE MANIFEST CACHE: https://www.google.com ブラウザがこのキャッシュを行う際 CORBのチェックを怠っていた為、
明示的にキャッシュしたリソースを使うことによって CORBがバイパス 出来た Chrome Securityチームが先に見つけていたので重複
レンダラプロセスを信頼しないSite Isolationへ 当初の目標であったレンダラプロセスを一切信頼しない脅威モデルの確立に向け て着々と実装が行われている • Out-of-Renderer CORS • 各IPCの再チェック •
現状の実装で実際のサイトが守れるかの確認 などなど
レンダラプロセスを信頼しないSite Isolationへ 当初の目標であったレンダラプロセスを一切信頼しない脅威モデルの確立に向け て着々と実装が行われている • Out-of-Renderer CORS • 各IPCの再チェック •
現状の実装で実際のサイトが守れるかの確認 などなど こちらも実際に見つかったバグを紹介します ※まだ実装が完璧ではない為、セキュリティのバグではなくセキュリティ機能の向上 として 扱われる場合があります
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!
ナビゲーションコミット時のオリジン偽装 Chromeにはナビゲーションが開始された後にレスポンスをロードする為のレンダ ラプロセスからナビゲーションをコミットするという概念がある Life of a Navigation:https://youtu.be/mX7jQsGCF6E Navigate to https://evil.tld
Commit navigation with https://victim.tld
UXSSに昇格 別オリジンにコミット出来ることは Chromeチームが知っていたので重複 レンダラプロセス自体は攻撃者のサイト用のままのなので UXSSが出来ない
UXSSに昇格 別オリジンにコミット出来ることは Chromeチームが知っていたので重複 レンダラプロセス自体は攻撃者のサイト用のままのなので UXSSが出来ない レンダラプロセスがアクセス出来るオリジンを確認されてしまう APIには オリジンの偽装がバレるが、そうでない APIは上手く騙せていた Service
Workerを使うサイトに対してはCache APIを使ってUXSSが出来た https://crbug.com/915396
postMessageのオリジン偽装 レンダラプロセス内のオリジンを偽装した後に postMessageすると メッセージを受け取った側に偽装されたオリジンが送られてしまう https://evil.tld https://victim.tld frames[0].postMessage(“hello”,”*”); alert(event.origin)// https://victim.tld $3000
https://crbug.com/915398
気をつけて欲しいこと 開発者へ • 信頼出来ないData URLをiframeで表示することはXSSではないが危険
気をつけて欲しいこと 開発者へ • 信頼出来ないData URLをiframeで表示することはXSSではないが危険 • HTML、XML、JSON以外の機密ファイルでクロスサイトに読み込まれる必要 がないものにはCORPヘッダーを設定しよう!
気をつけて欲しいこと 開発者へ • 信頼出来ないData URLをiframeで表示することはXSSではないが危険 • HTML、XML、JSON以外の機密ファイルでクロスサイトに読み込まれる必要 がないものにはCORPヘッダーを設定しよう! • https://www.chromium.org/Home/chromium-security/corb-for-developers
気をつけて欲しいこと 開発者へ • 信頼出来ないData URLをiframeで表示することはXSSではないが危険 • HTML、XML、JSON以外の機密ファイルでクロスサイトに読み込まれる必要 がないものにはCORPヘッダーを設定しよう! • https://www.chromium.org/Home/chromium-security/corb-for-developers
ユーザへ • 信頼出来ないローカルファイルは開かないようにしよう! (現状全てのFile URLは同一サイト)
Site Isolationで変わってきたこと • レンダラプロセスを掌握してもUXSSをする為には更にバグが必要になった
Site Isolationで変わってきたこと • レンダラプロセスを掌握してもUXSSをする為には更にバグが必要になった • ブラウザプロセスのアタックサーフェイスが増加した
Site Isolationで変わってきたこと • レンダラプロセスを掌握してもUXSSをする為には更にバグが必要になった • ブラウザプロセスのアタックサーフェイスが増加した • ブラウザのバグがサイトの設定で防げるようになってきた
Site Isolationで変わってきたこと • レンダラプロセスを掌握してもUXSSをする為には更にバグが必要になった • ブラウザプロセスのアタックサーフェイスが増加した • ブラウザのバグがサイトの設定で防げるようになってきた • SOPバイパスがSite
Isolation関連で守られていない所に集中し始めた
Site Isolationで変わってきたこと • レンダラプロセスを掌握してもUXSSをする為には更にバグが必要になった • ブラウザプロセスのアタックサーフェイスが増加した • ブラウザのバグがサイトの設定で防げるようになってきた • SOPバイパスがSite
Isolation関連で守られていない所に集中し始めた • Siteという概念がより強くなり始めた
Site Isolationをテストしたい方へ Spoof.js https://github.com/shhnjk/spoof.js Chromeのレンダラプロセス内のオリジンと URLを偽装してくれる WinDbgの拡張スクリプト オリジンとURLを偽装した後に任意のAPIを呼ぶことでそのAPIが偽装したオリジン やURLに騙されないか試せる
Questions? Acknowledgement: Thanks Chrome Site Isolation team! (nasko, lukasza, creis,
and others)