Impact of Cloudflare's incident on DigitalOcean

Impact of Cloudflare's incident on DigitalOcean

先週(2017/02/03)、Cloudflareでインシデントが発生しました。

これを受けて、DigitalOceanからCloudflareのインシデントによるDigitalOceanへの影響について説明する記事が公開されました。

先に結論

DigitalOceanから顧客データが流出する事態には(DigitalOceanのセキュリティチームによる調査によると)至っていない。

Cloudflareで何が起きたのか

インシデントの記事で詳細まで語られていますが、以下のような経緯がありインシデントが発生したようです(訳が雑・間違っている可能性有り ><)。

何が起きたか

HTTPクッキーやauthenticationトークン、HTTP POSTボディの内容などが検索エンジンにキャッシュされてしまった(ヤバイ)。

例えばCloudflareを通して何かの管理画面にアクセスして、そのセッショントークンがメモリリークによって流出、検索キャッシュに登録されてしまうとか多分そんな感じ。ヤバイ。

なぜ起きたか

Cloudflareはエッジサーバ(CDNの末端のサーバ)を通過するHTMLを解析・変更するのにRagelを使ったパーサを利用している。

パーサを使って例えばGoogleアナリティクスタグのリンクがhttpだったら安全のためhttpsに置き換えたり、その他色々な操作をしている。そしてCloudflareの多くのサービスはこのパーサに依存している(パーサは単一の.rlファイルに書かれているらしい...)。

Ragelを使ったパーサが複雑すぎて維持が大変になってきたので、代わりにcf-htmlという名前で新しくパーサを作り直した。Ragelを使ったパーサもcf-htmlもNginxのモジュールとして使われている。

これらのフィルタモジュールはHTMLを含むバッファ(メモリのブロック単位)を解析し、必要なら変更を加えバッファを次のフィルタへ渡している。

実はRagelを使ったパーサには以前からメモリリークのバグが有ったのだが(Ragel自体のバグではない)、Nginxの内部的なバッファを使っていたためにメモリリークが発生していなかった(?)。

cf-htmlを導入した際に、cf-html自体には問題がなかったのだが、そのバッファの処理が微妙に変更され、メモリリークが起きた。

メモリリークによって公開された情報はGoogleの検索結果にもインデックスされてしまっていた(対策済み)。


のような経緯らしいです。元記事にはCのコードも貼ってあり、より詳細な解説もされていました。

このインシデントはGoogleのゼロデイ攻撃対策チームであるProject Zeroによって報告されたらしい(カッコイイ)。

DigitalOceanへの影響

CloudflareからDigitalOceanへ、顧客データが検索キャッシュに公開されている事態は無かったと報告があり、またDigitalOceanのセキュリティチームも独自に調査したところ流出はなかったようです。ε-(´∀`*)ホッ

念のためDigitalOceanのエンジニアリングチームによって、ユーザの全てのセッショントークンをリセットしたとのこと。

しかしさらに念のため、DigitalOcean利用者には以下の操作をすることが推奨されています。

  • パスワードの更新
  • APIトークンの再作成
  • 2段階認証の設定

DigitalOceanチームはこの件について、引き続き状況を継続して監視していくとのこと。

感想

インシデントやセキュリティ周りの話は難しい話な場合が多くて理解するのが大変(カーネルの話とかC言語レベルの話とか)。低レイヤーの知識を身につけていきたい。(`・ω・´)ゞ

参考リンク

インシデントに対する記事。

プロジェクト・ゼロのブログ。

Ragelについて(るびまの記事)。