@znz blog

ZnZ の memo のようなもの

CVE-2014-0160 の OpenSSL の脆弱性対応

| Comments

Heartbleed によると今回の OpenSSL の脆弱性は影響が大きそうなので、 OpenSSL の更新をして再起動だけでも早めにした方が良さそうです。

再起動が必要なものは Debian なら debian-goodiesのcheckrestartで再起動が必要なプロセスを調べる のがオススメです。 Ubuntu なら libssl の更新は OS 自体を再起動した方が良いと思います。

秘密鍵を再生成した方が良いという話もあるようですが、 そこまでの対処は続報を待ってからでも良いかもしれません。

mod_spdy にも影響

(mod_spdy について 2014-04-09 に追記)

mod_spdy も影響を受けるので、 mod-spdy-beta パッケージの 0.9.4.1-r397 以前を入れている場合は最新版 (2014-04-09 リリースの 0.9.4.2-r413 以降) に更新する必要があります。

mod-spdy-beta に含まれる mod_ssl_with_npn.so は改変した libssl を静的リンクしているようなので、 システム側の OpenSSL が 0.9.8 系などのディストリビューション (wheezy など) でも以下のようになっていて、脆弱性の影響を受けます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ ldd /usr/lib/apache2/modules/mod_ssl.so
        linux-vdso.so.1 =>  (0x00007fff25b9a000)
        libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f6ae2d93000)
        libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f6ae299c000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6ae277f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6ae23f4000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6ae21f0000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6ae1fd8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6ae322d000)
$ ldd /usr/lib/apache2/modules/mod_ssl_with_npn.so
        linux-vdso.so.1 =>  (0x00007fff825ff000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8704d4e000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f8704b17000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f87048fa000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f87046f6000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f870436b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8705367000)

影響を受ける OpenSSL のバージョン

Heartbleed の What versions of the OpenSSL are affected? によると、影響を受けるのは OpenSSL 1.0.1 から 1.0.1f で、 OpenSSL 1.0.0 系や OpenSSL 0.9.8 系という古いバージョンは 影響がないようです。

Debian や Ubuntu への影響

他の OS も含めた情報は Heartbleed の How about operating systems? にまとまっているので、 Debian と Ubuntu に付いてもう少し調べてみました。

Heartbleed にも書いてありますが、 Debian – Security Information – DSA-2896-1 openssl によると Debian は oldstable (squeeze) は影響がなくて、 stable (wheezy) だと影響があるようです。 つまりまだ wheezy に上げていないサーバーは大丈夫でした。

USN-2165-1: OpenSSL vulnerabilities | Ubuntu によると Ubuntu は

  • Ubuntu 13.10 (saucy)
  • Ubuntu 12.10 (quantal)
  • Ubuntu 12.04 LTS (precise)

にセキュリティアップデートが出ているようです。 10.04 LTS lucid は openssl が古いので影響がなくて、 13.04 (raring) は サポート終了 しているので、セキュリティアップデートは出ていないようです。 ついでに DistroWatch.com: Ubuntu でもう少し調べてみると 1.0.1 になったのが 12.04 からなので、 11.10 以前は影響がないようです。

攻撃を受けたかどうかの確認はできない

Heartbleed に Can I detect if someone has exploited this against me? Exploitation of this bug leaves no traces of anything abnormal happening to the logs. と書いてあって、 「このバグを突かれても何か変なことがあったというログは残らない」 ということのようなので、 普通は攻撃を受けたかどうか確認できないということのようです。

秘密鍵は再生成するべき

というわけで、 DSA-2896to the currently available information, private keys should be considered as compromised and regenerated as soon as possible. と書いてあるように、 秘密鍵は出来るだけ早く再生成した方が良いようです。

openssh-server の鍵の再生成

2014-04-08 追記: OpenSSH は影響を受けない ようです。 (2014-04-09 23:55 追記: SSH の通信部分で OpenSSL を使っていないので、直接は影響を受けないというだけで、 PAM で LDAPS を使っている場合などは当然影響を受けます。)

サーバー側では /etc/ssh/ssh_host_* を削除して dpkg-reconfigure openssh-server で再生成するのが良さそうです。

1
2
3
4
5
6
7
8
9
10
% sudo rm /etc/ssh/ssh_host_*
% sudo dpkg-reconfigure openssh-server
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Creating SSH2 ECDSA key; this may take some time ...
ssh stop/waiting
ssh start/running, process 7230
% sudo service ssh restart
ssh stop/waiting
ssh start/running, process 7339

クライアント側では、 HashKnownHosts no を設定していれば ~/.ssh/known_hosts ファイルを直接編集しても良いのですが、 設定していないと、どの行がどのホストかわからないので、 ssh-keygen -R foo.example.jp のように削除すると良さそうです。

場合によっては ssh-keygen -R 192.168.1.2 のように IP アドレス側の削除や ssh-keygen -R '[foo.example.jp]:3843' のようにポート番号付きでの指定が必要かもしれません。

UserKnownHostsFileknown_hosts ファイルを分割しているときは ssh-keygen -R foo.example.jp -f ~/.ssh/foo.known_hosts のように UserKnownHostsFile を指定する必要があります。

その他のサーバーの鍵の再生成

apache2 とかの Web サーバーなら 初回の設定と同様に再生成すれば良さそうですが、 証明書の再発行も必要なので、 気軽には出来ないということで、 しばらく様子見中です。

OpenVPN はサーバーの鍵は再生成した方が良さそうですが、 CA まで再生成する必要があるのかどうかがわからないので 様子見中です。

以前の Debian での修正ミスで脆弱な鍵しか生成できなくなっていた問題の修正のときの Debian – 鍵のロールオーバー が参考になるかもしれませんが、 今回はサーバー外からでも鍵が抜き出せてしまうという問題のようなので、 LAN 内のサーバーなど、そのサーバーにアクセスできる環境に攻撃者が入れる時点で問題がある環境なら、 アップデートを適用して再起動して今後鍵を抜き取られる可能性をなくしてから、 ゆっくり続報を待ってから対処を考えるということでも良いと思います。

参考リンク

2014-04-09 参考リンクを追加

Comments