Heartbleed(ハートブリード)、私のハートブリードを聞いてください――OpenSSL脆弱性の本質と対策

日頃から私は、ソフトウェアセキュリティに関する話題にはかなり懐疑的なスタンスを取っています。セキュリティ業界の目的の一つは、人々を不安に駆り立ててセキュリティ製品を購入させることにある、とすら考えているからです。その最たる例が、Windows XPのサポート終了前後におけるマルウェア情勢をめぐる見解の対立でしょう。Microsoftは自社の新しいOSの方が安全だとするレポートを発表し、一方のアンチマルウェアベンダーは真逆の主張を展開しました。こうした経緯もあり、今回のOpenSSLの脆弱性という話題にも、私は当初やや冷ややかな目を向けていました。

とはいえ、複数の読者から「この件について詳しく解説してほしい」という要望を受けました。確かに今回はWindowsの話ではありません。Linuxであり、Webであり、まったく別次元の出来事です。これは興味深いテーマになりそうです。

Heartbleed(ハートブリード)とは何か

端的に言えば、HeartbleedとはOpenSSLのHeartbeat拡張機能に存在するバグです。このバグにより、Heartbeat要求を送った側が、対象システム上のOpenSSLライブラリのメモリから任意のデータを受け取れてしまいます。つまり、TLSプロトコル通信に必要なデータだけを返すべきところを、ポーリングされたホストが必要以上のデータを返してしまうのです。これは実質的に、要求元へ送信されることを想定していないメモリページへのアクセスを意味します。

以上が仕組みの説明です。問題は、これが大規模な顧客基盤を持つ多数のWebホスティングサービスやサイトに影響を及ぼしている点にあります。ここにおいて、Heartbleedは単なる「また一つのバグ」ではなくなるのです。

なぜこれが深刻なのか

はい、お聞きの通りです。これは深刻な問題だと私は考えています。ただし、標的となったサイトからどんなデータが収集されたか、という理由ではありません。機密情報の窃取こそが攻撃の目的であることは今も昔も変わりません。それは本質ではないのです。

重要なのは、この問題がどのように発生したかという点です。Heartbeatバグの原因は、大きく二つあります。第一に、入力値検証の欠如です。プログラミングにおける不滅の課題であり、開発者が変数の初期化、境界チェック、戻り値の確認を怠ってしまうという典型的なミスです。デスクに座る開発者を信用できない最大の理由ですが、残念ながら優秀なエンジニアにも起こり得ます。「Hello World!」の範囲を超えた途端、防げるものは限られてしまうのです。

第二の問題は、OpenSSLの開発者が、メモリを動的に確保・解放するfreeやmallocといったルーチンについて独自実装を使用していたことです。つまり、「自分たちは他の誰よりもよく分かっている」と考えたわけです。

このように分解してみると、実に厄介な話です。チェルノブイリ原発事故にも似ています。些細な問題の積み重ねが、ひとつの巨大な失敗へと膨れ上がったのです。

対処法――正しい視点を持つ

正直に言えば、一般ユーザーができることはほとんどありません。問題の大半はサーバー側にあるからです。確かに、脆弱なOpenSSLライブラリを使用するすべてのマシンが影響を受けます。しかし、あなたのデバイスがTLSを使って他のホストと直接通信する頻度はどれほどあるでしょうか? Webから情報を取得したり、ゲームサーバーに接続したりする程度のはずです。

一方、大規模サイトについては、私自身はこう考えています。仮に情報が流出していたとしても、トラフィック量が非常に大きいため、すべての情報を処理するには相当な計算能力が必要になりますし、メモリの内容も断片的すぎて、一貫した全体像を組み立てるのは困難だろう、と。

もちろん、これは数学的な論文ではなく私の推測です。したがって、毒舌は控えめにお願いします。考えてみてください。Googleを例にとると、同社は数万台のサーバーからなる巨大なコンピュートファームを持ち、それぞれが毎秒数百件のリクエストを処理しています。仮にこれらのリソースにheartbeat攻撃を仕掛けるとしても、データをすべて収集するには攻撃者側でも大量のサーバーが必要です。さらに、SSLのデータを必死に集めている攻撃者がいるなら、DoS攻撃でリソースを落としたくはないはずです。第三に、仮に認証情報が盗まれていたとしても、スイッチ型ネットワーク上でトラフィックを有意義に傍受することは容易ではありません。

これは皆さんを安撫しようと言っているのではありません。そういう話ではなく、問題を合理的に検証する必要がある、ということです。つまり、理論上、そしておそらく実際にも、一部のSSLデータは漏洩した可能性があります。予防措置として、パスワード変更を推奨するウェブサイトもあります。これは決して悪くない習慣です。加えて、二要素認証の導入や、サイトごとに異なるパスワードを使うことも良いアイデアです。

少し安心材料になるのは、企業環境における世界のインストール基盤の大部分が、古いバージョンのエンタープライズ向けディストリビューションで稼働しており、その多くは影響を受けていないという点です。古いCentOSなどを「時代遅れでダサい」と揶揄するかもしれませんが、このケースでは意外な形で役立ったわけです。

エンドユーザーとしてできること

模範的なユーザーでありたいなら、できることがいくつかあります。よく使う人気サイトが、依然として脆弱なバージョンを使っていないか確認しましょう。もし使っているようなら、報告し、問い合わせ、修正を求めましょう。ユーザー側でできるのは、だいたいそれくらいです。

パスワードについては先述の通りです。忘れてはならないのは、このバグは2012年初頭から存在し、発覚まで2年以上経過していたという事実です。それまで誰も気づいていなかったということは、おそらく問題が広範かつ密かに悪用されることはなかったのでしょう。もし悪用されていたなら、2年前から現在までの間に情報が漏洩していた可能性があります。物事を正しい視点で捉えることが大切です。

自分でサイトを運営しているなら、責任を持ってシステムをアップデートし、影響を受けるサービスを停止・再起動して、新しいライブラリをメモリにロードしてください。そして何より重要なのは、中堅以下のコンサル会社が開発した、静的にコンパイルされた独自のOpenSSLを使用する粗悪なアプリケーションがないか確認することです。静的リンクされたOpenSSLは、せっかく適用したアップデートを参照せず、使い続けてしまう恐れがあります。

陰謀論

当然ながら、新たなNSA監視陰謀説も登場しています。あの三文字の機関が、このバグを何年も前から知っていたという主張です。私に言わせれば、これは疑わしい話です。Googleのエンジニアを含む二つの異なる組織と、フィンランド(つまり米国ではない)の企業Codenomiconが、ほぼ同時にこのバグを報告したからです。これは「新しい何か」が起きたことを示唆しています。

それでもNSAが心配なら、こんな処方箋はいかがでしょうか。Michael Mannをご存知ですか? 『マイアミ・バイス』や『ヒート』など数々の名作を手掛けた監督です。『Manhunter』(ハンニバル・レクターものとしては『レッド・ドラゴン』よりはるかに優れた作品)も彼の映画です。そして、そのテーマ曲こそが「Heartbeat」なのです。この曲は『マイアミ・バイス』の名エピソードのひとつにも使われています。聴けば、すべてが完璧に理解できるはずです。

ハートビート、ハートビート、私のハートビートを聞いて、オー・オー

まとめ

おそらく初めてのことでしょう。Dedoimedoが「これは本当に真剣に扱うべきセキュリティ問題だ」と認めるのは。いつものような煽りではなく、です。Heartbleedによるメモリリークは、日常的なマルウェアのたわごとではありません。同時に、これは主に企業やサービスプロバイダーが対応すべき問題でもあります。あなたの役割は小さなものです。大事なのは、冷静さと合理性を保つことです。

覚えておいてください。インターネットの背骨が痛むときは、身を引いて眺めるのが得策です。こんなことは毎日起こるものではありませんし、「あなたのPCは危険にさらされているかもしれない」といういつものたわごとの、さわやかな変化でもあります。今回は、あなたより大きな話なのです。だから、リラックスしましょう。

それでは、また。