Hatena::ブログ(Diary)

めもおきば このページをアンテナに追加 RSSフィード

Contact: akitan@gmail.com
noteにて投げ銭受付中 ⇒ 【投げ銭】こたろー写真

2014-04-08

CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ

必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。

どうすればいいのか

  1. OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ
  2. あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも)
  3. SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。
  4. サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。
  5. PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。

漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして別の記事に書きましたのでそちらをご覧くださいまし。

影響を受けるディストリビューション

基本的には、パッケージ更新などでOpenSSLをバージョンアップして、そのあとOpenSSLを読んでいるサービスを再起動します。外部サーバへの接続なども含めるとOpenSSLを利用するサービスが多いので、よく分からない人はサーバごと再起動がおすすめ。

1.0.1からの新機能による脆弱性なので、1.0.0とそれ未満であれば問題ありません。逆に、1.0.1eやそれ以前のバージョン番号のまま脆弱性のみ修正される場合もあるので、OpenSSLのバージョンだけでなく、パッケージのバージョンを確認してください。

ディストリ どうすればいいか
Debian Wheezy (stable)以降DSA-2896-1
stable: libssl1.0.0 1.0.1e-2+deb7u5 で修正
testing/unstable: libssl1.0.0 1.0.1g-1 で修正
Ubuntu 12.04.4 LTS以降[USN-2165-1]
12.04: libssl1.0.0 1.0.1-4ubuntu5.12 で修正
12.10 libssl1.0.0 1.0.1c-3ubuntu2.7 で修正
13.10 libssl1.0.0 1.0.1e-3ubuntu1.2 で修正
RHEL 6.5 [RHSA-2014:0376-1]
openssl-1.0.1e-16.el6_5.7で修正
CentOS 6.5 [CESA-2014:0376]
openssl-1.0.1e-16.el6_5.7 で修正
Scientific Linux 6.5 openssl-1.0.1e-16.el6_5.7 で修正
Fedora 18以降 [Bug 1085065]
Fedora 19: openssl-1.0.1e-37.fc19.1 で修正
Fedora 20: openssl-1.0.1e-37.fc20.1 で修正
(Fedora 18はサポート切れのため公式パッケージ無し)
OpenBSD 5.3以降 [Patches for OpenSSL bounds checking bug]
パッチあり: 5.3 / 5.4 / 5.5
FreeBSD ports [[ports] Revision 350548]
security/openssl 1.0.1_10 で修正
FreeBSD 10.0 [FreeBSD-SA-14:06.openssl]
freebsd-updateでバイナリ更新するかpatchあててbuildworld/installworld/reboot
NetBSD pkgsrc [NetBSD Security Advisory 2014-004]
openssl-1.0.1gで修正
NetBSD 6.0以降 [NetBSD Security Advisory 2014-004]
各arch向けにビルド済みバイナリが配布されている。
OpenSUSE 12.2 [openSUSE:Maintenance:2718]
Amazon Linux 2013.03以降[Thread: openssl heartbleed]
ALAS-2014-320: openssl Security Update - Information Disclosure Vulnerability]
2013.09: openssl-1.0.1e-4.58.amzn1 で対応
2014.03: openssl-1.0.1e-37.66.amzn1.x86_64 で対応
Amazon ELB [HeartBleed Bug Concern]
[AWS Services Updated to Address OpenSSL Vulnerability / 参考和訳]
全てのRegionで対応済み、ただし証明書の更新を推奨
(リスクの度合いは不明)
Amazon CloudFront [AWS Services Updated to Address OpenSSL Vulnerability / 参考和訳]
対応済み、ただし証明書の更新を推奨
(リスクの度合いは不明)
Homebrew [openssl 1.0.1g]
brew update
brew upgrade openssl
brew link openssl --force
(コメ欄にて詳しい手順有り)
Gentoo Linux [GLSA 201404-07 / openssl]
dev-libs/openssl-1.0.1g で修正
BIG-IP [SOL15159: OpenSSL vulnerability CVE-2014-0160]
11.5.0以降が影響を受ける模様
「Use only Native SSL stack ciphers」に設定していれば回避可能
Google Compute Engine [Security Bulletins]
各ディストリの v20140408 以降のイメージで作り直すか、yum/aptでパッケージ更新
Android 4.1.1 [Google Services Updated to Address OpenSSL CVE-2014-0160 (the Heartbleed bug)]
Android 4.1.1のみ影響
ChromeはOpenSSLを使わない(NSS)のため影響外

自前で入れたり、バージョンアップがすぐにできない場合は、「-DOPENSSL_NO_HEARTBEATS」を設定し、OpenSSLをコンパイルしてもよい。

  • 影響を受けない主要ディストリ:
  • 個別のベンダー製品については、各社のURLが以下の記事に集約されているのでこちらを探してください。

その他影響を受けるソフトウェア

ソフトウェア対応
Cygwin [Updated: openssl-1.0.1g-1]
openssl-1.0.1g-1 で対応
TeraTerm(TTProxy) 影響無し
当初「SSH部分に影響無し、TTProxyでSSL利用時のみ影響を受ける可能性」と書いていましたが、今のところSSL通信をしないとのこと[出典]
Apache mod_spdy 独自OpenSSLを内部で持つのでv0.9.4.2に上げる(出典)
Phusion Passenger [Phusion Passenger 4.0.41 released, OpenSSL Heartbleed security update]
OpenSSLを静的リンクしており4.0.41未満で影響あり
Ruby RVM [rvm/config/db]
rvm管理下で別にopensslを入れた場合は対応が必要
Ruby rbenv/ruby-build [OpenSSL library updated to 1.0.1g #547]
ruby-buildプラグインで別にopensslを入れた場合は対応が必要
plugins/ruby-build下でgit pullしてrbenv installしなおす
OpenVPN [OpenVPN 2.3.2 Windows build I004 リリース]
[OpenSSLの脆弱性 – Heartbleed について]
Windows版バイナリにOpenSSLが含まれるため、OpenVPN側のバージョンアップも必要。
Android版クライアントもAndroid 4.1(.0)と4.1.1は影響を受けるのでAndroid対応待ち
TLS-Authを使っていなければ影響は無い。TLS-Authを使っていれば影響は無い。
修正(2014/04/10 18:24)
TLS-Authの記述が逆になっていました。TLSハンドシェークの前にHMACによるチェックを挟む機能で、有効にしていれば影響を受けません。こちらの記事に詳しく書かれています。
FFFTP [臨時版 1.98g1 - FFFTP]
FTPS(FTP over TLS/SSL)のみ影響、1.98g1 で対応
WinSCP [OpenSSL vulnerability CVE-2014-0160]
5.5.3で対応予定
通常のSCP/SFTPには無関係、FTP over TLS/SSLを使っている場合のみ影響
  • オープンソースプロジェクトのWindows用バイナリは該当する可能性が高いです。

関係しそうなサービス

何が起きているの

OpenSSLに脆弱性があり、SSLで通信している相手のメモリを閲覧できます*1

具体的には、以下のようなシナリオが考えられます。

  • 攻撃者がクライアント側の場合、 HTTPSサーバのSSL証明書秘密鍵が漏洩する。
  • 攻撃者がクライアント側の場合、 HTTPSサーバのプロセス内にあるユーザー情報が漏洩する。特にApache+mod_php5のコンボでは、ウェブアプリ内の全ての情報が見られる可能性がある。
  • 攻撃者がサーバ側の場合、HTTPSで外部のAPIサーバ等に接続したアプリケーションが、メモリ内にあるユーザー情報等が漏洩する。
    • これが危険になるケース: HTTPSのCommonNameの検証をきちんと行っていない場合や、審査が緩いCAが同じ名前でSSL証明書を発行した場合、外部APIサーバのSSL証明書秘密鍵が奪取された場合など
    • 04/08 22:34追記: そもそもハンドシェークフェーズなので証明書の検証は無関係でした。DNS毒入れ等の併用で攻撃者のSSLサーバに接続させられてしまえば無条件でやられます。
  • 攻撃された記録は一切残らない。安全側に倒すならば、脆弱性のあるバージョンをインターネットに公開していたら攻略されたとみなす方が良い。

SSL証明書等の扱い

脆弱性のあるバージョンを使っていた場合、最悪でSSL証明書秘密鍵が奪取されている可能性があります。この場合、現在使っているSSL証明書を失効(revoke)させ、再発行する必要があります。

証明書の失効方法については、SSL証明書を発行したCAに問い合わせてください。CA側で管理する証明書失効リストに掲載され、漏洩した秘密鍵によるSSL証明書が使えないようになります。例えばSymantec(旧Verisign)であればストアフロントから失効申請ができるようです。

直接の関係が無いもの

  • あくまでSSL通信(TLSプロトコル)上の脆弱性のため、OpenSSLライブラリを使っていても、OpenSSHやGnuPG(PGP)などには直接は関係しません。ただし、OpenSSHがLDAP等で外部へのSSL通信を行う場合、そこから攻撃される可能性が残ってはいます。
  • 読み取られるのは、SSL通信を行っているプロセスのメモリ内容のため、ロードバランサや前段のApache等でSSL処理を行っている場合は、別プロセスのアプリケーションサーバ内のメモリ内容は漏洩しません。ただし、前述の通り外部へのSSL通信を行っている場合は別です。
    • curlコマンドを別プロセスで起動している場合*2や、OpenSSL以外のライブラリを使っている場合も無関係です。
  • そのプロセスが読んでいない無関係なファイル等は、たとえそのプロセスの実行ユーザにパーミッションが開かれていても漏洩しません。あくまでプロセスのメモリ内容のみです。

関連URL

*1:64KB単位で何度でも繰り返せる。要するにSR双葉杏が引けるまで何度でも引けるガチャ。

*2:RHEL6/CentOS6系のcurlはOpenSSLのかわりにNSSを使っているため影響を受けないようです。

riocamposriocampos 2014/04/08 19:57 まとめ感謝です。
Homebrewの欄が抜けていたのでご報告を(はてダにも書きましたが

$ brew update
$ brew upgrade openssl
で1.0.1gに更新されます。
念のため
$ brew link openssl --force
でhomebrew側にリンクし
$ which openssl

/usr/local/bin/openssl
であることを確認。
homebrewのopenssl formula更新履歴は
https://github.com/Homebrew/homebrew/commits/master/Library/Formula/openssl.rb
に載ってます。

nekorurinekoruri 2014/04/08 20:06 ありがとうございます、
自分がhomebrew使っていなかったもので助かります。
本文に追記入れました!

riocamposriocampos 2014/04/08 20:16 直ぐに追記して頂いて感謝です!
見直したら「はてブ」と書いたつもりが「はてダ」になってて恥ずかしいw

aa 2014/04/08 20:27 攻撃者がサーバ側の場合ですがCommonNameの検証をしたとしても
攻撃者が正規の手順で証明書を取得している場合は攻撃されてしまうのでは?

nekorurinekoruri 2014/04/08 20:35 >>攻撃者が正規の手順で証明書を取得している場合は攻撃されてしまう
もちろんそのとおりですね、追記しました。

nekorurinekoruri 2014/04/08 22:24 どうもNetBSDはbaseは6.0以降で、heartbleed.comの「NetBSD 5.0.2 (OpenSSL 1.0.1e)」はpkgsrcのようです。FreeBSDについても似たような感じなので分離させました。

nekorurinekoruri 2014/04/08 22:35 上で話が出ていたCN検証の話ですが、そもそもハンドシェークフェーズなので証明書が正当である必要すら無かったです。本文にも追記済み。

252525252525 2014/04/08 23:23 Vyyataは影響あるのでしょうか・・・

エスロジカルエスロジカル 2014/04/08 23:53 海外版SSL(RapidSSL、ジオトラスト、ベリサイン(シマンテック)、ソート)の再発行手順
https://www.slogical.co.jp/ssl/faq/re_issuance

ここから〜ここまで、に記載の手順はエスロジカル以外からご購入の場合でも可能。
間違えてキャンセルしないようにご注意ください。

qwertyqwerty 2014/04/09 00:03 https://twitter.com/ttdoda/status/453538091995643905

nekorurinekoruri 2014/04/09 01:05 >https://twitter.com/ttdoda/status/453538091995643905
本文にある通りTTSSHというかSSH自身には影響無いですね。TTProxyのSSL部分を使っていない人は無関係のはずです。

nekorurinekoruri 2014/04/09 01:06 >Vyyataは影響あるのでしょうか・・・
古めのDebianベースでOpenSSL 0.9.xとのことなので影響は無いようです。
http://twitter.com/ysaotome/status/453555886121029633

252525252525 2014/04/09 03:08 なるほど。ありがとうございます。
AWSのELB、BIG-IPは痛いですね・・・

252525252525 2014/04/09 09:43 ELBは対応完了した模様です。us-east除く。
http://aws.amazon.com/jp/security/security-bulletins/aws-services-updated-to-address-openssl-vulnerability/

nekorurinekoruri 2014/04/09 10:33 今見たらELBは全て対応済みのようです。CloudFrontもかな。
ただ、SSL証明書の更新を推奨(recommend)となっていて、どれぐらいリスクがあったのかが分からないですね。まあ細かいことは気にせず再発行/失効コンボ決めろってことでしょう。

ysaotomeysaotome 2014/04/09 13:41 VyOSの公式アナウンスはこちらです。

No action is needed.
http://vyos-dev.tumblr.com/post/82073944861/cve-2014-0160

nekorurinekoruri 2014/04/09 13:57 >>VyOSの公式アナウンスはこちらです。
ありがとうございます、リンク加えておきました。

ttkzwttkzw 2014/04/09 16:44 Amazon Linux 2013.09用の対応パッケージもあります。
openssl-1.0.1e-4.58.amzn1
https://forums.aws.amazon.com/thread.jspa?messageID=535546&tstart=0

nekorurinekoruri 2014/04/10 15:26 >>Amazon Linux 2013.09用の対応パッケージもあります。
ありがとうございます、追記しました。
Security Bulletinも出ていたのでそちらもリンク済みでし。

nekorurinekoruri 2014/04/10 18:25 すみません、OpenVPNのTLS-Authに関する記述が逆になっていました!
肝心な部分で、先入観から誤訳してしまいました……。

ふうせん Fu-sen.ふうせん Fu-sen. 2014/04/11 12:00 FFFTP はプロジェクトに参加しているので、更新版を確認しました。WinSCP 同様 FTPS で影響があります。
Windows 版の場合でも 1.0.1 ではなく 1.0.0 や 0.9.8 系を使っている場合があります。
(Dropbox は 0.9.8 系らしい?)なので、OpenSSL 使っていれば全て該当というわけではありません。
これは Linux でも同じです。Tiny Core Linux は 1.0.0 系でパッケージ提供していたので非対称です。
Puppy Linux は 1.0.1 が一部採用されていたので、ちょっと大変な事になっています。
KNOPPIX も対象かと思いますが、更新版を出すんでしょうか? ちょっと気になってます。

エスロジカルエスロジカル 2014/04/11 12:40 失効(revoke)方法について追記しました。
https://www.slogical.co.jp/ssl/faq/re_issuance
※SSL証明書の再発行後に失効してください。
ベリサイン(現シマンテック)とソートは管理画面から、RapidSSLとジオトラストは代理店経由での失効となります。

hnakamur3hnakamur3 2014/04/11 23:53 よいまとめをありがとうございます。

サーバだけではなくクライアント上の情報も盗まれるというブログ記事が出ていました。
http://blog.meldium.com/home/2014/4/10/testing-for-reverse-heartbleed
https://news.ycombinator.com/item?id=7569163

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

リンク元