Cloudflareのバグで別のユーザーのCookieやパスワードが送信される 17
ストーリー by headless
通過 部門より
通過 部門より
CloudflareのHTMLパーサーのバグにより、同社のリバースプロキシを使用するWebサイトにアクセスすると、別のユーザーのCookieや認証トークン、パスワード、APIキーなどを含むデータが送信される状態になっていたそうだ(Cloudflareのブログ記事、
Project Zero — Issue 1139、
The Registerの記事、
The Vergeの記事)。
このバグはバッファー終端のチェックで「>=」ではなく「==」を使用していたため、ポインターがバッファー終端を超えていることを認識できないというものだ。そのため、破損したHTMLタグを含むページを処理するとバッファーオーバーランによるメモリーリークが発生し、別のユーザーのデータが一緒に送信されることになる。バグを発見したGoogleのTavis Ormandy氏は、Heartbleedのようなバグと説明しつつ、「Cloudbleed」と呼ばないように求めているが、既にロゴも作られてしまっている。
このバグはバッファー終端のチェックで「>=」ではなく「==」を使用していたため、ポインターがバッファー終端を超えていることを認識できないというものだ。そのため、破損したHTMLタグを含むページを処理するとバッファーオーバーランによるメモリーリークが発生し、別のユーザーのデータが一緒に送信されることになる。バグを発見したGoogleのTavis Ormandy氏は、Heartbleedのようなバグと説明しつつ、「Cloudbleed」と呼ばないように求めているが、既にロゴも作られてしまっている。
このパーサーは数年前から使われているが、バッファーの扱いが異なっていたため問題が発生することはなかったという。しかし、新パーサーへの移行を開始した際にバッファーの扱いが変更されたことで、影響が表面化することになる。影響を受けた機能は「Email Address Obfuscation」「Server-side Excludes」「Automatic HTTPS Rewrites」だが、2月13日に移行を始めたEmail Address Obfuscationの影響が最も大きいとのこと。
18日にGoogleのTavis Ormandy氏からバグ報告を受けたCloudflareでは、これらの機能を数時間のうちに無効化し、21日までにバグを修正して再度有効化している。また、GoogleやBingなどサーチエンジンがキャッシュしたページにもユーザーのデータが含まれている可能性があるため、各社の協力によりバグ公表前にキャッシュデータのクリアも行われたとのことだ。
Cloudflareでは影響を受けるWebサイトを公表していないが、CloudflareのDNSを使用するドメインのリストがGitHubで公開されている。ただし、リストに含まれるすべてのドメインが影響を受けるとは限らず、リストに含まれないドメインが影響を受ける可能性もある。データは400万件を超える大規模なものだが、README.mdには有名サイトおよびAlexa top 10,000のサイトが抜粋されているので、参照するといいだろう。また、ドメインを入力することでCloudflareを使用しているかどうかを確認できる「Does it use Cloudflare?」というWebサイトも公開されている。
影響を受けるWebサイトを利用している場合、パスワードの変更やログアウト、新しいAPIキーへの切り替えなどが推奨される。なお、SSLサーバー証明書の秘密鍵は漏洩していないとのことだ。
Project Zeroのリンク先にもありますが (スコア:1)
「で、こないだのGoogle一斉ログアウト事件はこれに関係するの？」
「いや、関係ない」
「でもタイミング良すぎじゃね？」
「関係ない。このスレッドをクローズする」
ってやりとりがまさに「言えばいうほど嘘っぽい」状態になってて笑える。
# 真実は闇の中...
Re: (スコア:0)
「で、こないだのGoogle一斉ログアウト事件はこれに関係するの？」
「いや、関係ない」
「でもタイミング良すぎじゃね？」
「関係ない。このスレッドをクローズする」
ってやりとりがまさに「言えばいうほど嘘っぽい」状態になってて笑える。
# 真実は闇の中...
Ｙｅｓ
Re: (スコア:0)
？？？
Re: (スコア:0)
たまにアンサクロペディアを見ようとするとCloudflareのDDOS攻撃のページが表示されて何も表示されなくなるのも関係ある?
Re: (スコア:0)
いや、関係ない
Re: (スコア:0)
昔々emobileで6時間、S社のネトゲで15分で自動切断の仕様があったんが・・・・・。
どちらも自動切断超えても回線が切れない事がたまにあって、一度自動切断を超えると二度と自動切断が働くことはなかった。
あれは、"=="で条件判断していたんだろうなぁ・・・・。当時から夢想していた。
5:59:59→6:00:01や14:59→15:01で負荷等で丁度の時刻を跳び越すと"=="が成立しなくて自動切断が働かないだろうなぁと。
Re: (スコア:0)
指摘する側がエビデンス出さないと、なんでもありの世界になっちゃうんじゃ…
新人にまかせた部分とか (スコア:0)
バッファオーバーフローとかうるさく言われる時代にこの終端チェックは凄いな。
自分も新人のころにやらかした記憶がある。
ユニットテストとかやっていない開発フローなんですかね。
Re: (スコア:0)
ユニットテスト以前に、ループ抜け判定==は意図しないバグで無限ループさせてしまうので避けるようにするとかは、
・本人が直感的に思う
・人に即座に指摘される
どちらかだと思うんですけどねえ。。
Re:新人にまかせた部分とか (スコア:1)
後から変なもん付け足されて、、、なんてことは結構あるから、それに備えた書き方という奴だよ。
少数含む型に変えられて、、とか演算子オーバーロードで、、いうのは実際見たw
で、元を作った人が責められる理不尽さw
Re: (スコア:0)
end()と!=の実装次第では？
終端を超えているときend()の戻り値を!=演算子で評価してtrueになればよいのだから。
Re: (スコア:0)
==で終端チェックしてるからオーバーランするわけじゃなくて、オーバーランした時に被害が拡大するに過ぎない。
（==をすり抜けるということは、その時点で既にオーバーランしている。）
だから、==で終端チェックしているかどうかは、ユニットテストでテストしようがない。
また? (スコア:0)
CloudFlareのEmail Protectionは以前2chに導入されて、XSSを引き起こしていましたね (スラドの記事 [it.srad.jp])。
ちゃんとテストされてないのかな?
Re: (スコア:0)
あそこら辺の商品は認めたくない人が自発的に無料で協力してくれるから