OpenSSLの脆弱性で想定されるリスク (original) (raw)
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。
今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ)
- インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。
- このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。
- 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例)
他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。
まだ直っていないウェブサイトもあれば、元々壊れていないウェブサイトもあるので、「直したからパスワード変更してね」って言ってきたら変更してください。あと、悪い人が偽メール送ってきているので、メールで連絡してきたとしても、ブラウザのブックマークから開きましょう。
ここからはエンジニア向けの詳細です。
今回の脆弱性の内容
いわゆる「SSL通信」と呼ばれる暗号化通信は、実際にはSSL 3.0とより新しいTLS 1.0〜1.2（互換性のためプロトコル上の番号は3.1〜3.3）というプロトコルで定義されています。これらを使うために、様々なソフトウェアが利用している共通ライブラリが OpenSSL です。今回の脆弱性は、このTLS 1.2に追加されたハートビート拡張*1の実装の不具合によるものです。
SSL通信の最初「ハンドシェーク」段階でSSL証明書の検証などを行いますが、今回の脆弱性はそのハンドシェーク段階の中でも発生する*2ため、正しいSSL証明書を持っていなくても攻撃が成立します。ほとんどの場合にログが残らないのもこのためです。
攻撃者は、通信の相手のメモリ内容を取得することができます。一回で最大64キロバイト、同じプロセス内の情報に限られますが、ログに残らず、めぼしい情報が取得できるまで何度でも繰り返すことができるため（これがメモリガチャと呼ばれる理由）、プロセス内の全ての情報が漏洩したと考えるべきです。
「同じプロセス」というところが問題で、どのプロセスがSSL通信をしたかによってリスクが大きく変わります。
ApacheでSSLを提供し、脆弱性があった場合 (mod_php5,mod_perl等)
mod_php5やmod_perlなどを利用し、Apacheモジュールとしてウェブアプリケーションを動かしていた場合です。
これまで登場した全ての内容に加えて、以下の内容が漏洩します。
- 全てのアプリケーションコード
- 全てのアプリケーション設定
- DB等から取得したメモリ上のデータ全般(別リクエストの内容も、場合によって空きメモリに残っている可能性がある)
ここまでくると、想定されるリスクはかなり大きいです。
- 別ユーザからのリクエストに含まれた、パスワードや個人情報、クレジットカード番号、セキュリティコードなどが空きメモリに残っていた場合、それが漏洩します。
- Cookieベースセッションは、自由にセッションデータの捏造ができます。
- インターネットからDBサーバ等に直接接続ができなくとも、別の攻撃を行うための予備情報を攻撃者に与えることになります。
PHPであっても、PHP-FPMを使うなどApacheとプロセスを分けることで、権限ごと分離できるので、今回を期に挑戦すると良いのでは無いでしょうか*4。
外部のサーバ等にSSL通信を行っている場合
SSH系を除くほぼ全てのクライアントアプリケーションの暗号化通信が当てはまりますし、サーバ側であっても、外部のAPIサーバへの通信などにはあてはまります。
あくまでこの場合、攻撃者が用意したサーバに接続しない限り安全であると考えられますが、その一方で、DNSキャッシュポイズニングやBGPのハイジャックなど、攻撃する側がトラフィックを呼び込むための手法が存在しています。
これをされた場合、そのクライアントが持っている接続先リストやそこに含まれるユーザー・パスワードが漏洩します。
外部に接続するサーバ側アプリであれば、前述の「ApacheでSSLを提供し、脆弱性があった場合 (mod_php5,mod_perl等)」と同等です。例えばSSLサーバとしては社内からの接続しか受けていなかったとしても、抜け道があるので、やはり上げておきましょう、ということです。