OpenSSL Heartbleedとはなんだったのか。CVE-2014-0160

Ads by Google

世間を賑わせたHeartbleedとはなんだったのか。

OpenSSL TLS の ‘Heartbeat’ 拡張機能に存在する情報漏えいの脆弱性(CVE-2014-0160)
が4月に見つかり世間を騒がせました。

既に落ち着いているものですが、ちょっと振り返ってみます。

Heatbeatとは

OpenSSLにはHeartbeatという拡張機能があります。

この拡張機能は、実際の通信が発生しない間においても
SSLやTLSのセッションを維持するというもの。

これにより、まだ、コンピュータ同士が通信状態としては
接続されいている状態となり、通信が出来る状態と判断
されます。

そのため、最初の接続が切断されても、もう一度接続を確立する
際に資格情報を入力する手間を省くことができます。

実際の接続確立の手順は以下の通り。

  1. HeartbeatがOpenSSLサーバにメッセージを送信
  2. OpenSSLがメッセージを送信者に戻す

一体何が問題なのか?

実はこのメッセージというのがくせ者で、そのデータには
最大64kbのデータパケットと、そのサイズ情報が含まれています。

でも、Heartbeatの脆弱性を悪用して、このサイズの情報を偽装する
ことが出来てしまうんです。1kbを64kbのように。

で、なんでこれが問題になるかというと
Heartbeatメッセージを処理する方法に問題があるわけです。

OpenSSLは送られてきた実際のデータとデータサイズの
一致性の検証を行わないんですね。

そうするとどんなことが起こるかというと、OpenSSLは
データサイズ側を正として判断してしまうため、実際には
1kbしか無いデータであったとしても、データサイズとして
偽装された64kbというデータという情報が送られてくると、
それをそのままのデータ量として返そうとしてしまいます

そこに、重要なユーザのログイン情報や、パスワード、
個人のデータ、さらにセッション鍵や秘密鍵が含まれて
しまう恐れがあるわけです。

これがHeartbleedの脆弱性ですね。

この仕組みからだと、最大でも1回に63kbのデータを
受信できることになる訳ですが、これを繰り返し
繰り返し行うことで、多くのデータを入手する
ことにつながり、重要なデータを盗み出すこと
が出来る可能性がある訳です。

対応方法は?

SSLにおける最大の問題は、秘密鍵を盗まれた場合の
ことです。

しかし、この秘密鍵が盗まれる可能性はきわめて低い
ようです。

理由としては、通信のデータは新しいデータの方が
古いデータより前に格納されるもの。

秘密鍵情報というのは、通常メモリ上で後ろの方に
格納されるので、アクセスされる可能性がきわめて
低いとのこと。

とはいえ、少しでもリスクがある場合にはセキュリティ
の観点から「対処」することが求められるわけです。

よって、OpenSSLを利用しているサーバでは、SSL
サーバ証明書の取得し直しが推奨されたわけです。

ここで対象となるのは、OpenSSLの1.0.1から1.0.1f。

ただし、この間のバージョンでもディストリビュータに
よっては、パッチを当てて対処しているものもあるので
一概にバージョンだけで判断できないことがあります。

分からない場合は、サーバ会社などに確認する必要が
あります。

まぁ、不安であれば、1.0.1gへアップデートするんですね。
それが確実です。

OpenSSL側の対処が終わったら、秘密鍵を生成しなおして
SSLサーバ照明書の再発行をします。

ベンダによっては有償かもしれません。手続き方法は
各ベンダに聞いてください。

ちなみに、再発行するときはちゃ〜んと秘密鍵の作り直し
からする必要がありますので、注意してくださいね。

CSRは秘密鍵が一緒でもいくつでも作れます。
秘密鍵は同じで、CSRだけ作り直して再発行
なんて意味のないことがないように。

イントラネットでしか使ってない、なんてこともあるかも
しれませんが、そのイントラ上に悪意持った人間がいないと
も言い切れませんので、対処することが推奨ですね。

さらに、これの対象はOpenSSLですからね。
それ以外のMicrosoft IISやJavaなんか使っている場合は
対処の必要ありませんので。

Ads by Google

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

Ads by Google

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA