AWS環境のPOODLE脆弱性対応 (CVE-2014-3566)

miida.makoto

2014.10.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、三井田です。

米国時間の10/14、SSLv3のPOODLE問題というセキュリティ脆弱性(CVE-2014-3566)について詳細がアナウンスされました。

参考リンク；

AWSでもそれに併せて、セキュリティアドバイザリを発行しています。

CVE-2014-3566 Advisory

この記事では、これらの参考情報をもとに、この脆弱性に対する対処を簡単に案内したいと思います。

POODLEアタックとは

OpenSSLのドキュメントによると、POODLEとは"Padding Oracle On Downgraded Legacy Encryption"の略とのことです。

暗号化された通信内のCookie情報などが、plaintextとして参照される恐れがあるとのことです。

影響範囲

脆弱性がシステムに与える影響ですが、

今回の脆弱性は、旧来使用されていたSSLv3に存在する仕様上の問題です。
影響範囲についていくつか気に留めておく必要があることを記載します。

今回の脆弱性は、サーバ側だけではなく、SSLv3を使用するクライアント側（ブラウザやHTTPS通信をつかうアプリケーションなど）にも影響があります
SSLv3をもとに標準化され、後方互換性をもつTLSv1.0では影響はありません
TLSv1.1以降では影響はありません

対策

AWSのセキュリティアドバイザリによると、AWSのサービスとしては、Elasitc Load Balancing (ELB)と、CloudFrontを利用の場合に対応が必要なケースがあるようです。

その他、EC2上で、ApacheやNginx、PostfixなどでSSLを利用している場合にも対応が必要なケースがあると考えます。

端的にいうと、以下のいずれかの対策が必要です。この記事では、前者を紹介したいと思います。

SSLv3を使用しないよう設定する
「TLS_FALLBACK_SCSV」により、旧バージョンのSSLを使用する試み (downgrade) を阻む

EC2での対策

【更新】2014/10/16（日本時間）に、POODLE脆弱性対応を含んだOpenSSL 1.0.1jに対応したopensslパッケージが、Amazon Linuxで利用可能となりました。

Amazon Linux AMI Security Centerの以下のエントリーを参照しましょう。

ALAS-2014-426: CVE-2014-3566 (POODLE)対応
ALAS-2014-427: その他OpenSSL 1.0.1jに反映された CVE-2014-3513, CVE-2014-3567, CVE-2014-3568に対する対応

POODLE対応(ALAS-2014-426)については、最新のバージョン以外にもAmazon Linux 2013.03, 2013.09でも利用可能となっています。詳細はSecurity Advisoryを参照してください。

現時点では、こちらのスレッドHow do I patch/workaround SSLv3 POODLE vulnerability (CVE-2014-3566)?に、クライアント側、サーバ側それぞれでの対策がよくまとまっていましたので、サーバ側に絞って紹介します。
（詳細は、リンク先を参照ください）

Apache HTTPDサーバ

SSLの設定ファイル（RHEL系のOSでmod_sslをインストールした素の状態だと一般的に、/etc/httpd/conf.d/ssl.conf）で、SSLProtocolの設定を以下のようにし、httpdをリスタートします。

SSLProtocol All -SSLv2 -SSLv3

sudo service httpd restart

Nginxサーバ

設定ファイルで、SSLを使用せずTLSだけを使用するよう設定します。

【修正 2014/10/15 19:00】
ssl_protocolsの設定の誤りを修正しました。@ijinさん、ご指摘ありがとうございます。

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

sudo service nginx restart

Postfixサーバ

Apache HTTPDサーバと同様に、SSLv3を使用しないよう設定します。

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3

sudo postfix restart

Windows Server

追記 2014/10/15 15:50 JST
Windows関連の情報を匿名さんから頂いたので追記しました。

Windowsプラットフォームについては、Microsoft社がMicrosoft Security Advisory 3009008を公開しました。

IISなどでWebサーバを公開している場合は、同様にSSLv3を無効化します。設定方法は、公式ナレッジベースのインターネットインフォメーションサービスで PCT 1.0、SSL 2.0、SSL 3.0、または TLS 1.0 を無効にする方法や、IIS で SSL 3.0 を無効にする方法が参考になります。

Elasitic Load Balancing (ELB)での対策

こちらは、AWSのセキュリティアドバイザリをもとに、実際にAWSマネジメントコンソールでの設定を紹介します。

端的には、SSLv3をネゴーシエーションオプションから外したCypherの設定「ELBSecurityPolicy-2014-10」が用意されたので、そちらを利用するようにします。

新規起動のELB

HTTPSなどSSLを利用するListner設定で、自動的に「ELBSecurityPolicy-2014-10」が利用されます。

既存のELBの設定変更

AWSマネジメントコンソールを開き、ELBの画面に移動します。（コンソール -> EC2 -> Load Balancer と選択）
ELBを選択し、Listnersタブを開きます
該当のポートの「Cypher」列の「Change」をクリックします
ドロップダウンより「ELBSecurityPolicy-2014-10」を選択して「Save」します

CloudFrontでの対策

AWSのセキュリティアドバイザリによると、独自SSLを使用しているディストリビューションの場合、影響があるとのことです。

独自SSLを使用していない場合は、影響は無い模様です。

ディストリビューションの設定で、「Only Clients that Support Server Name Indication (SNI)」を選択することで影響を回避できます。

しかしながら、上記は「SNI 独自 SSL」方式を採用する手順と認識しており、「専用IP 独自SSL」の場合の対処については情報収集中です。

【追記：2014/10/21】
日本時間 10/18に、CloudFrontのアップデートについてセキュリティアドバイザリに追記がありました。
SSLv3に対するポリシー変更を含む大きな変更となるようなので、別記事 POODLE (CVE-2014-3566)に関するCloudFrontの仕様変更に切り出してまとめましたので、参考にしてください。