DROWN: SSLv2 を使用した TLS へのクロスプロトコル攻撃 (CVE-2016-0800)

Red Hat Product セキュリティーチームは、SSLv2 プロトコルの脆弱性を認識しており、[CVE-2016-0800] (https://access.redhat.com/security/cve/CVE-2016-0800) で、DROWN (Decrypting RSA using Obsolete and Weakened eNcryption) と呼ばれるクロスプロトコル攻撃で利用されるこの脆弱性に対応しています。

概要

セキュリティー関連の調査グループは、SSLv2 (Secure Sockets Layer プロトコルバージョン 2.0) が Bleichenbacher RSA パディングオラクル攻撃に対して脆弱であることを発見しました。この脆弱性は、一致する RSA プライベートキーを知らなくても RSA 暗号文を復号化できるように利用される可能性があります。これは、攻撃者がプライベートキーを持つサーバーの応答を観察し、そのキーを使用して独自の暗号文を復号化することで実行されます。さらにこの調査グループは、この SSLv2 の弱点を利用することで、SSLv3 または最新の TLS (Transport Layer Security) バージョン (1.0 - 1.2) などの新規バージョンのプロトコルを使用した SSL/TLS セッションの復号化も可能にする新規のクロスプロトコル攻撃についても説明しています。本件の脆弱性は SSLv2 プロトコルの問題であり、このプロトコルのすべての実装に影響を与えます。調査グループはこの攻撃を 一般的な DROWN として言及しています。

ほかにも、脆弱性は OpenSSL 暗号および SSL/TLS ライブラリーの SSLv2 プロトコルの実装で確認されています。これらの脆弱性は 特殊な DROWN と称されるより効率的な DROWN攻撃の実行を可能にします。これらの脆弱性については、CVE-2016-0703 および CVE-2016-0704 で対応されており、最近の CVE-2015-0293 のフィックスの対象の一部としてすでに修正されています。

この攻撃に関する詳細は、「DROWN: Breaking TLS using SSLv2」(https://drownattack.com/drown-attack-paper.pdf) というタイトルの調査グループの文書を参照してください。

背景情報

SSLv2 プロトコルには既知のセキュリティー脆弱性があり、その置き換えとなる SSLv3 が公開された 1996 年以来安全性に欠けるプロトコルと見なされてきました。さらに 2011 年には、SSLv2 プロトコルは RFC 6176 によって正式に非推奨プロトコルとなりました。最新の SSL/TLS クライアントはこのプロトコルのバージョンをまったくサポートしないか、または可能な場合はこれより新しいバージョンを使用するため、このプロトコルのインターネットでの使用は限られています。しかし、多くの SSL/TLS サーバーは依然としてこのプロトコルを有効にします。この設定により、非常に古くなったクライアントによる接続も可能になります。今回の DROWN 攻撃の公開前には、新しいバージョンのプロトコルをサポートするクライアントからの接続のセキュリティー脅威についての報告はありませんでした。

DROWN 攻撃によって影響を受ける設定

SSLv3 または TLSv1.x に加えて SSLv2 プロトコルを有効しているサーバー、および RSA 鍵交換暗号スイート (RSA key exchange cipher suite) を使用するサーバーは DROWN 攻撃に対して脆弱になります。SSLv2 を有効にしていないサーバーでも、SSLv2 を有効にしている別のサーバーまたはサービスとその RSA プライベートキーを共有する場合は脆弱になる可能性があります。たとえば、SSLv2 を有効にしていない web サーバーが 、SSLv2 を有効にしていて、同じホストで実行されている可能性のある IMAP サーバーとその RSA キーを共有する場合は、HTTPS セッションをその web サーバーに復号化するために DROWN 攻撃が利用される可能性があります。この攻撃を効率よく実行するには、SSLv2 の脆弱な暗号または輸出暗号が必要になります。

Diffie-Hellman や Elliptic Curve Diffie-Hellman などの RSA 以外の鍵交換を使用する SSL/TLS 接続については、DROWN 攻撃を利用して復号化することはできません。

攻撃の詳細と影響

調査グループによると、DROWN 攻撃は以下のステップで構成されます。

• まず、攻撃者は任意のバージョンのプロトコルと RSA 暗号スイートを使用するクライアントとサーバー間の SSL/TLS セッションについて、その特定の数のセッションを記録する必要があります。これらの記録されたセッションの 1 つが復号化されます。調査グループは、この攻撃の実行に必要なセッション数は約 1,000 であると示唆しています。

• 次に、攻撃者は数多くの SSLv2 接続をサーバーに対して開きます。これらの接続の中には、攻撃者が 40 ビット (SSLv2 輸出暗号のいずれかが使用されている場合) または 56 ビット (DES を使用する暗号スイートの場合) のセッションキーに対してブルートフォース攻撃を実行します。調査グループは、これを実行するのに必要な接続数は約 40,000 であると推定されています。

• 上記の後に、攻撃者は最初に記録されたハンドシェイクのいずれかから「プリマスターシークレット」データを復号化できます。このデータは対称セッションキーを生成し、記録された SSL/TLS セッション全体を復号化するために使用されます。また、認証資格情報や cookie などの追加の機密データもこの復号化されるセッションから取得できます。

調査グループは、2048 ビット RSA キー、1,000 の記録されたハンドシェイク、 40,000 の SSLv2 接続、および 2⁵⁰ のオフライン計算を使用してサーバーとの TLS 1.2 ハンドシェイクを復号化したことを説明しています。調査グループの実施した攻撃には、8 時間未満の時間と 440 ドル (USD) 相当のパブリッククラウドプロバイダーのリソースが費やされました。

また調査グループは、特殊な DROWN 攻撃の場合は SSLv2 接続の数は 14,000 に削減でき、単一ワークステーションを使って 3 分未満で実行できるとしています。この脆弱性を利用する攻撃により、中間者 (MITM) 攻撃を実行し、TLS サーバーを偽装して TLS クライアントに接続することが可能になります。

SSLv2 サポートのある SSL および TLS ライブラリー

Red Hat 製品には、SSLv2 プロトコルのサポートを実装する以下のコンポーネントが含まれます。このサポートは、アプリケーションによる SSL/TLS ライブラリーの使用方法に応じて有効にされます。

OpenSSL の SSLv2

OpenSSL を使用するアプリケーションは、使用する SSL/TLS プロトコルのバージョンをライブラリーに通知するための接続メソッドを選択する必要があります。OpenSSL の接続メソッドが単一のプロトコルバージョンを有効にするか、または特殊なメソッドの SSLv23 を使用してライブラリーがサポートするすべてのプロトコルバージョンを有効にすることができ、これは最も一般的に使用される接続メソッドです。SSLv2 プロトコルは、このメソッドが選択されると自動的に有効にされます。アプリケーションでは、SSLv2 を無効にするには関連のSSL_CTX または SSL オブジェクトで SSL_OP_NO_SSLv2 オプションを明示的に設定する必要があります。多くのアプリケーションでは、無条件にまたは設定に基づいてこの設定を実行しますが、有効にされたプロトコルのデフォルトセットを使用するアプリケーションも存在します。そのため、OpenSSL ライブラリーを使用するアプリケーションは SSLv2 を有効にした状態で実行される可能性が高くなります。

この脆弱性に対応するために、以下の変更が Red Hat 製品に含まれる OpenSSL に適用されました。

• SSLv2 プロトコルは SSLv23 接続メソッドを使用する場合にデフォルトで有効にされなくなりました。
• 40 ビット (輸出) または 56 ビット (単一 DES) の対称暗号キーを使用するすべての SSLv2 暗号スイートは無効にされており、使用することができなくなりました。以下の暗号スイートは利用不可になりました。
  • EXP-RC2-CBC-MD5 / SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
  • EXP-RC4-MD5 / SSL_CK_RC4_128_EXPORT40_WITH_MD5
  • DES-CBC-MD5 / SSL_CK_DES_64_CBC_WITH_MD5
• Red Hat Enterprise Linux 4 および 5 のすべてのアップデートに含まれる openssl パッケージの OpenSSL バージョンは OPENSSL_ENABLE_SSL2 環境変数をチェックし、これが定義されている場合は、SSLv23 接続メソッドを使用する際に SSLv2 がデフォルトで有効にされます。この環境変数は必要に応じて SSLv2 を再度有効にするために使用されます。

SSLv2 接続メソッドは SSLv23 接続メソッドの変更による影響を受けず、SSLv2 プロトコルを使用した接続を設定するために依然として使用できます。

また、Red Hat Enterprise Linux 6 および 7 で同梱される OpenSSL バージョンの デフォルト 暗号リストではすべての SSLv2 暗号スイートが除外されていますが、このデフォルト設定は、サーバーによる、無効にされた暗号スイートを強制的に使用するクライアントからの SSLv2 接続の受け入れを防ぐ訳ではありません。この脆弱性については、CVE-2015-3197 で対応されており、DROWN 脆弱性に対応するアップデートで修正されています。

NSS (Network Security Services) の SSLv2

NSS 暗号ライブラリーは SSLv2 プロトコルを実装しますが、これをデフォルトで有効にしません。アプリケーションはこのライブラリーに対して、SSLv2 を有効にして使用できるように明示的に指示する必要があります。Red Hat Enterprise Linux 7 に同梱される NSS のバージョンは SSLv2 プロトコルの有効化を許可しません。そのため NSS ライブラリーを使用するアプリケーションについては、SSLv2 が有効な状態で実行される可能性は低くなります。

NSS ライブラリーはデフォルトで SSLv2 を有効にしないため、DROWN 脆弱性対策としてのアップデートは近い将来に予定されていません。Red Hat Enterprise Linux 6 の今後のアップデートでは、Red Hat Enterprise Linux 7 で無効にされているのと同様の方法でこのプロトコルが無効にされる見通しです。

SSLv2 サポートのない SSL および TLS ライブラリー

Red Hat 製品には、TLS または SSL プロトコルの特定のバージョンを実装するものの、SSLv2 のサポートは実装しない以下のコンポーネントが含まれます。これらのコンポーネントはこの脆弱性の影響を受けません。ただし、これらの影響を受けないライブラリーを使用するアプリケーションでも、それらが SSLv2 をサポートする SSL/TLS ライブラリーを使用する別のアプリケーションとそれらのプライベート RSA キーを共有する場合には DROWN 攻撃による影響を依然として受ける可能性があります。

• GnuTLS
• OpenJDK (パッケージ java-1.6.0-openjdk、java-1.7.0-openjdk、java-1.8.0-openjdk)
• Oracle JDK (パッケージ java-1.6.0-sun、java-1.7.0-oracle、java-1.8.0-oracle)
• IBM JDK (パッケージ java-1.6.0-ibm、java-1.7.0-ibm、java-1.7.1-ibm、java-1.8.0-ibm)

解決策

Red Hat は、お客様に対し、影響を受けるシステムの優先順位についてリスクベースの分析を行い、問題修正に利用できるパッチをすぐに適用されることをお勧めします。システム更新後の再起動は、影響を受けるすべてのサービスにアップデート済みの OpenSSL ライブラリーを使用させるための最も安全な方法になります。再起動できない場合は、パッチ適用後に OpenSSL に依存するすべてのネットワークサービスを再起動する必要があります。

謝辞

Red Hat は OpenSSL プロジェクトがこれらの問題を報告してくださったことに感謝の意を表します。また、最初の報告者である Nimrod Aviram および Sebastian Schinzel に対してもアップストリームから感謝の意を表します。

よくある質問

アプリケーション X で SSLv2 を無効にするには?

各種の Red Hat Enterprise Linux バージョンに同梱される各種アプリケーションで、プロトコルバージョンの有効化などの SSL/TLS 関連の設定を変更する方法の詳細は、ナレッジベースの記事 Securing Application 'X' in RHEL 'Y' ? を参照してください。

この脆弱性のために、サーバーのキーまたは証明書を再生成する必要はあるか?

いいえ。DROWN は RSA プライベートキーを直接的に公開することはありません。ただし、SSL/TLS 接続ハンドシェイクで生成され、対称暗号で使用される個別のセッションキーが攻撃の対象となります。それらのキーが脆弱性によって危険にさらされた場合には、特定の SSL/TLS セッションが復号化されます。そのため、サービスの DROWN 攻撃への脆弱性が検出されたとしても、サービスのキーまたは証明書を再生成する必要はありません。

Red Hat 製品に同梱される Apache httpd web サーバーのバージョンで SSLv2 は有効にされているか?

Apache httpd web サーバーは以下のモジュールのいずれかを使用して HTTPS サービスを提供します。

• mod_ssl: このモジュールは OpenSSL 暗号ライブラリーを使用し、Apache httpd サーバーディストリビューションの一部として組み込まれています。
• mod_nss: このモジュールは NSS 暗号ライブラリーを使用し、Apache hプロジェクトとは別に開発され、配布されています。

上記のモジュールの両方が Red Hat 製品に含まれています。

mod_ssl を使用する httpd のデフォルト設定:

• Red Hat Enterprise Linux 7、Red Hat Software Collections のhttpd24 コレクションおよび Red Hat JBoss Web Server 3 に同梱される httpd バージョンは、アップストリームの httpd バージョン 2.4 をベースとしており、SSLv2 プロトコルを有効にするように設定することはできません。

• Red Hat Enterprise Linux 5 および 6、Red Hat JBoss Web Server 1 および 2、ならびに Red Hat JBoss Enterprise Application Platform 6 に同梱される httpd バージョンは、アップストリームの httpd バージョン 2.2 をベースとしています。これらのバージョンは SSLv2 を使用するように設定できますが、このプロトコルはデフォルト設定で無効にされています。/etc/httpd/conf.d/ssl.conf 設定ファイルには SSLv2 を無効にする以下の設定ディレクティブが含まれています。

SSLProtocol all -SSLv2

• Red Hat Enterprise Linux 4 に同梱される httpd バージョンはアップストリームの httpd バージョン 2.0 をベースとしています。デフォルト設定は SSLv2 を有効にしますが、上記と同じ SSLProtocol ディレクティブを /etc/httpd/conf.d/ssl.conf 設定ファイルに追加し、httpd サービスを起動することにより、このプロトコルを無効にすることができます。

mod_nss を使用する httpd のデフォルト設定:

• Red Hat Enterprise Linux 5、6、および 7 に同梱される mod_nss バージョンは、SSLv2 をデフォルトで有効にしません。mod_nss パッケージのバージョンによりますが、/etc/httpd/conf.d/nss.conf 設定ファイルには、SSLv3 以降または TLSv1.0 以降のみを有効にする以下の設定ディレクティブのいずれかが含まれます。

NSSProtocol SSLv3,TLSv1
NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

注意: SSLv3 プロトコルには既知の問題があるため、弊社ではこのバージョンも無効にすることを今後も推奨します。詳細および Red Hat 製品の各種コンポーネントで SSLv3 プロトコルを無効にする方法については、関連の POODLE: SSLv3 脆弱性 (CVE-2014-3566) 記事を参照してください。

SSLv2 は Red Hat Enterprise Linux に同梱されるメール SMTP サーバーで有効にされるか?

Red Hat Enterprise Linux 5、6、および 7 の Postfix および Sendmail メールサーバーの両方のデフォルト設定は SSL/TLS 暗号をサポートしません。

システム管理者が Postfix で SSL/TLS を有効にする場合、デフォルトでは SSLv2 は日和見暗号 (opportunistic encryption) の場合は有効に、強制的な暗号 (mandatory encryption) の場合は無効にされます。Red Hat Enterprise Linux 6 および 7 では、smtpd_tls_protocols 設定オプションを使用して日和見暗号の場合でも SSLv2 を無効にできます。

システム管理者が Sendmail で SSL/TLS を有効にする場合、SSLv2 はデフォルトで有効にされます。Red Hat Enterprise Linux 5、6 および 7 では、ServerSSLOptions 設定オプションを使用して SSLv2 を無効にできます。

Postfix および Sendmail で SSL/TLS を設定する方法についての追加の参考情報へのリンクは、上記の「アプリケーション X で SSLv2 を無効にするには?」を参照してください。

EWS 6.4 インストールを更新する必要はあるか?
EAP は、Java 暗号プロバイダー (JSSE) またはネイティブプロバイダー (APR/OpenSSL) を使用するように設定できます。APR/OpenSSL プロバイダーを使用している場合は、以下のステップを実行してください。

• Red Hat Enterprise Linux
  お使いのバージョンの OpenSSL をアップグレードします。
• Windows または Solaris
  openssl ライブラリーのアップデートはカスタマーサービスプラットフォームで利用できます。このアップデートは libssl および libeay ライブラリー、および openssl アプリケーションに置き換わります。

EAP 6.4 については、APR/OpenSSL を使用した Windows でのテストが実施済みです。OpenSSL ライブラリーのアップデートは必要ですが、EAP 6.4 はデフォルトで TLSv1 を使用し、SSLv2 および SSLv3 の暗号化要求を拒否します。現時点で EAP はこの脆弱性の影響を受けないことが予想されています。

EWS 5.2 インストールを更新する必要はあるか?
EAP は、Java 暗号プロバイダー (JSSE) またはネイティブプロバイダー (APR/OpenSSL) を使用するように設定できます。APR/OpenSSL プロバイダーを使用している場合は、以下のステップを実行してください。

• Red Hat Enterprise Linux
  お使いのバージョンの OpenSSL をアップグレードします。
• Windows または Solaris
  openssl ライブラリーのアップデートはカスタマーサービスプラットフォームで利用できます。このアップデートは libssl および libeay ライブラリー、openssl アプリケーションに置き換わります。

EAP 5.2 については、この脆弱性による影響度を評価するための Windows を使ったテストが現在実施されています。

EWS 2.1 インストールを更新する必要はあるか?
この脆弱性は、APR/OpenSSL がセキュリティープロバイダーとして設定されている Windows および Solaris インストールのみに影響を与えます。EWS 2.1 は現在 SSLv2 および SSLv3 をサポートしています。
APR/OpenSSL プロバイダーを使用している場合、以下のステップを実行してください。

• Red Hat Enterprise Linux
  お使いのバージョンの OpenSSL をアップグレードします。
• Windows または Solaris
  openssl ライブラリーのアップデートはカスタマーサービスプラットフォームで利用できます。このアップデートは libssl および libeay ライブラリー、openssl アプリケーションに置き換わります。

はい。EWS 2.1 は影響を受けます。アップデートはカスタマーサービスポータルより入手できます。この脆弱性は、APR/OpenSSL がセキュリティープロバイダーとして設定されている Windows および Solaris インストールにのみ影響を与えます。デフォルトの JSSE 設定は影響を受けません。アップデートはカスタマーサービスポータルより入手できます。

EWS 3.0.2 インストールを更新する必要はあるか?
この脆弱性は、APR/OpenSSL がセキュリティープロバイダーとして設定されている Windows および Solaris インストールのみに影響を与えます。EWS 3.0.2 は現在 SSLv2 および SSLv3 をサポートしています。EWS 3.0.3 がリリースされると、SSLv2 または SSLv3 は提供されなくなります。

APR/OpenSSL プロバイダーを使用している場合、以下のステップを実行してください。

• Red Hat Enterprise Linux
  お使いのバージョンの OpenSSL をアップグレードします。
• Windows または Solaris
  openssl ライブラリーのアップデートはカスタマーサービスプラットフォームで利用できます。このアップデートは libssl および libeay ライブラリー、openssl アプリケーションに置き換わります。

tomcat ネイティブパッケージの状況は?

tomcat ネイティブパッケージはこの脆弱性による影響を受けません。tomcat ネイティブパッケージは、システムが提供する OpenSSL ライブラリーに依存します。