若干古い記事だが引用。
<
OpenSSLに再び脆弱性、MITM攻撃につながる恐れ
http://www.atmarkit.co.jp/ait/articles/1406/06/news037.html
オープンソースのSSL/TLS実装「OpenSSL」に、新たに複数の脆弱(ぜいじゃく)性が発見された。中にはMITM攻撃につながるおそれのある問題も含まれており、修正版0.9.8za/1.0.0m/1.0.1hへのアップグレードが呼び掛けられている。
オープンソースのSSL/TLS実装「OpenSSL」に、新たに複数の脆弱(ぜいじゃく)性が発見された。中にはMan-in-the-Middle(MITM)攻撃によって、暗号化通信の内容を第三者(=攻撃者)が読み取ったり、改ざんしたりすることができる深刻な脆弱性も含まれている。
開発元のOpenSSLプロジェクトは米国時間の2014年6月5日、セキュリティアドバイザリを公開し、6つの問題を修正したバージョン0.9.8za/1.0.0m/1.0.1hへのアップグレードを呼び掛けた。Ubuntu、FreeBSD、RedhHatといった各ディストリビューションも修正版の配布を開始している。
このうちMITM攻撃につながる脆弱性(CVE-2014-0224)は、「ChangeCipherSpec (CCS) Injection Vulnerability」と呼ばれており、日本のネットワーク/セキュリティ技術・研究開発企業、レピダムの菊池正史氏が発見した。公開されたブログによると、この脆弱性はOpenSSLの最初のリリースから存在しており、16年もの間発見されてこなかった。原因は「TLS/SSLを実装したことのある経験者が十分にレビューできてなかったこと」にあるという。
脆弱性はOpenSSL 0.9.8y以前の全てと1.0.0~1.0.0l、1.0.1~1.0.1gに存在する。OpenSSLのハンドシェーク中に、不適切な状態でChangeCipherSpecを受理してしまうことが原因となって、第三者が知ることのできる「弱い鍵」を使用させるよう仕向けることができる。この結果、本来ならば適切に暗号化されるはずの通信内容や認証情報など重要な情報を、攻撃者によって詐取/改ざんされる恐れがある。プロトコルや暗号アルゴリズムには依存せず、影響を受ける恐れがあるという。
MITM攻撃を実行するには、クライアント側とサーバー側がともに脆弱性が存在するOpenSSLを利用しており、しかもサーバーがバージョン1.0.1以降である必要がある。
ただ、「最近、Heartbleed対策でサーバー側のOpenSSLが更新された結果、攻撃可能な範囲が広がった可能性が高い」(レピダム)。同社は、MITMという攻撃の性質上、状況次第であるとしながらも、場合によっては「Heartbleedと同等か、それ以上深刻な問題となる可能性がある」と考えているという。
また、サーバー側だけが脆弱性が存在するOpenSSLを利用している場合は、クライアントの偽装攻撃が行われる恐れがある。
【6月6日21時追記】
レピダムは脆弱性に関する情報を更新し、上記の、サーバー側のみに脆弱性が存在する場合に起こり得るとしていた「クライアントの偽装攻撃」(被害者のクライアントになりすましての認証ハイジャック)の可能性はないことを明らかにした。
この脆弱性について検証したIIJ-SECTは、攻撃が成立するには「条件がある」ことを踏まえ、「使用しているOpenSSLのバージョンやSSL/TLS通信の利用の仕方に応じて、アップデートの緊急性を個別に検討する余地がある」と述べている。
対策は前述の通り、脆弱性を修正したバージョンにアップデートすること。回避策などは公開されていない。なお、この脆弱性を悪用した攻撃を受けても形跡は残らないため、過去に攻撃を受けたかどうかを確認することは困難だ。ただ、不正侵入検知システム(IDS)などで、通常と異なるタイミングで送信されるChangeCipherSpecパケットを検知するよう構成すれば、攻撃の検知は可能と思われる。
OpenSSLについては2014年4月に、サーバーのメモリ上の情報を読み取られる恐れのある脆弱性「Heartbleed」が存在することが指摘され、多くの管理者が対応に追われたばかりだ。
>
実際の指摘記事を見てみる。
<
CCS Injection脆弱性(CVE-2014-0224)発見の経緯についての紹介 - OpenSSL #ccsinjection Vulnerability
http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection/index.html
菊池です。CCS Injection脆弱性(CVE-2014-0224)発見の経緯について紹介します。
バグの簡単な解説
OpenSSLがハンドシェーク中に不適切な状態でChangeCipherSpecを受理してしまうのが今回のバグです。 このバグはOpenSSLの最初のリリースから存在していました。
Message flow for a full handshake
通常のハンドシェークでは、右の図のような順序でメッセージを交換します(RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2 §7.3より作成)。
ChangeCipherSpecは必ずこの位置で行うことになっています。OpenSSLもChangeCipherSpecをこのタイミングで送信しますが、受信は他のタイミングでも行うようになっていました。これを悪用することで、攻撃者が通信を解読・改ざん可能です。
>
なるほど、全然分からん。
ハンドシェイク時のプロセスの下位にChangeCipherSpecがあるが、これが上位で発生させられてしまうことに伴う脆弱性を利用した攻撃があるらしいが、どうして上位で発生するのよ、という部分が分からない。というか記事に書いてない。
こういうのって、通信時に上位プロセスのチェックとかってないのかな?
上記とは別ラインで、Googleが動いている模様。
<
グーグル、OpenSSLの新たなforkとして「BoringSSL」発表 - @IT
http://www.atmarkit.co.jp/ait/articles/1406/23/news117.html
グーグルがOpenSSLのforkを発表、独自の実装にOpenSSL側の変更をマージする体制を採る。OSSでの展開はしない方針だという。
米グーグルが、オープンソースのSSL/TLS実装「OpenSSL」から新プロジェクトの「BoringSSL」を派生させた。同社の研究者アダム・ラングリー氏が2014年6月20日、自身のブログ「ImperialViolet」で明らかにした。
ラングリー氏によると、グーグルでは「Heartbleed」と呼ばれる重大な脆弱性が発覚する以前からOpenSSLのコードを検証し、何年にもわたって多数のパッチを使用してきた。この中にはOpenSSLのメインレポジトリに採用されたものもある一方で、OpenSSLが保証するAPIやABIの安定性とかみ合わないものや、やや実験的過ぎるものも多かったという。
しかし、AndroidやChromeなどの製品でそうしたパッチのサブセットが必要になる中で、パッチの数は70を超え、複数のコードで横断的に管理する作業は手に負えなくなってきたという。
そこでモデルを切り替えて、OpenSSLの上に変更を積み重ねるのではなく、OpenSSLから変更を取り込む「BoringSSL」をスタートさせることにした。BoringSSLはまずChromiumで着手し、いずれAndroidやグーグル社内のプロジェクトにも採用したい意向だという。
BoringSSLのコードではAPIやABIの安定性は保証せず、OpenSSLの代替となるオープンソースプロジェクトを目指すつもりもないとラングリー氏は説明する。今後もOpenSSLの変更は取り入れ、バグを見つければ報告する方針。
OpenSSLの派生プロジェクトとしては、OpenBSD Foundationも4月に「LibreSSL」を発表しているが、BoringSSLではLibreSSLからの変更も取り入れやすくなるといい、LibreSSLがグーグルの変更を取り入れることも歓迎するとした。
OpenSSLなどのオープンソース技術を資金面で援助する「Core Infrastructure Initiative」や、OpenBSD Foundationへの資金提供は今後も続けると表明した。
>
<
OpenSSLに再び脆弱性、MITM攻撃につながる恐れ
http://www.atmarkit.co.jp/ait/articles/1406/06/news037.html
オープンソースのSSL/TLS実装「OpenSSL」に、新たに複数の脆弱(ぜいじゃく)性が発見された。中にはMITM攻撃につながるおそれのある問題も含まれており、修正版0.9.8za/1.0.0m/1.0.1hへのアップグレードが呼び掛けられている。
オープンソースのSSL/TLS実装「OpenSSL」に、新たに複数の脆弱(ぜいじゃく)性が発見された。中にはMan-in-the-Middle(MITM)攻撃によって、暗号化通信の内容を第三者(=攻撃者)が読み取ったり、改ざんしたりすることができる深刻な脆弱性も含まれている。
開発元のOpenSSLプロジェクトは米国時間の2014年6月5日、セキュリティアドバイザリを公開し、6つの問題を修正したバージョン0.9.8za/1.0.0m/1.0.1hへのアップグレードを呼び掛けた。Ubuntu、FreeBSD、RedhHatといった各ディストリビューションも修正版の配布を開始している。
このうちMITM攻撃につながる脆弱性(CVE-2014-0224)は、「ChangeCipherSpec (CCS) Injection Vulnerability」と呼ばれており、日本のネットワーク/セキュリティ技術・研究開発企業、レピダムの菊池正史氏が発見した。公開されたブログによると、この脆弱性はOpenSSLの最初のリリースから存在しており、16年もの間発見されてこなかった。原因は「TLS/SSLを実装したことのある経験者が十分にレビューできてなかったこと」にあるという。
脆弱性はOpenSSL 0.9.8y以前の全てと1.0.0~1.0.0l、1.0.1~1.0.1gに存在する。OpenSSLのハンドシェーク中に、不適切な状態でChangeCipherSpecを受理してしまうことが原因となって、第三者が知ることのできる「弱い鍵」を使用させるよう仕向けることができる。この結果、本来ならば適切に暗号化されるはずの通信内容や認証情報など重要な情報を、攻撃者によって詐取/改ざんされる恐れがある。プロトコルや暗号アルゴリズムには依存せず、影響を受ける恐れがあるという。
MITM攻撃を実行するには、クライアント側とサーバー側がともに脆弱性が存在するOpenSSLを利用しており、しかもサーバーがバージョン1.0.1以降である必要がある。
ただ、「最近、Heartbleed対策でサーバー側のOpenSSLが更新された結果、攻撃可能な範囲が広がった可能性が高い」(レピダム)。同社は、MITMという攻撃の性質上、状況次第であるとしながらも、場合によっては「Heartbleedと同等か、それ以上深刻な問題となる可能性がある」と考えているという。
また、サーバー側だけが脆弱性が存在するOpenSSLを利用している場合は、クライアントの偽装攻撃が行われる恐れがある。
【6月6日21時追記】
レピダムは脆弱性に関する情報を更新し、上記の、サーバー側のみに脆弱性が存在する場合に起こり得るとしていた「クライアントの偽装攻撃」(被害者のクライアントになりすましての認証ハイジャック)の可能性はないことを明らかにした。
この脆弱性について検証したIIJ-SECTは、攻撃が成立するには「条件がある」ことを踏まえ、「使用しているOpenSSLのバージョンやSSL/TLS通信の利用の仕方に応じて、アップデートの緊急性を個別に検討する余地がある」と述べている。
対策は前述の通り、脆弱性を修正したバージョンにアップデートすること。回避策などは公開されていない。なお、この脆弱性を悪用した攻撃を受けても形跡は残らないため、過去に攻撃を受けたかどうかを確認することは困難だ。ただ、不正侵入検知システム(IDS)などで、通常と異なるタイミングで送信されるChangeCipherSpecパケットを検知するよう構成すれば、攻撃の検知は可能と思われる。
OpenSSLについては2014年4月に、サーバーのメモリ上の情報を読み取られる恐れのある脆弱性「Heartbleed」が存在することが指摘され、多くの管理者が対応に追われたばかりだ。
>
実際の指摘記事を見てみる。
<
CCS Injection脆弱性(CVE-2014-0224)発見の経緯についての紹介 - OpenSSL #ccsinjection Vulnerability
http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection/index.html
菊池です。CCS Injection脆弱性(CVE-2014-0224)発見の経緯について紹介します。
バグの簡単な解説
OpenSSLがハンドシェーク中に不適切な状態でChangeCipherSpecを受理してしまうのが今回のバグです。 このバグはOpenSSLの最初のリリースから存在していました。
Message flow for a full handshake
通常のハンドシェークでは、右の図のような順序でメッセージを交換します(RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2 §7.3より作成)。
ChangeCipherSpecは必ずこの位置で行うことになっています。OpenSSLもChangeCipherSpecをこのタイミングで送信しますが、受信は他のタイミングでも行うようになっていました。これを悪用することで、攻撃者が通信を解読・改ざん可能です。
>
なるほど、全然分からん。
ハンドシェイク時のプロセスの下位にChangeCipherSpecがあるが、これが上位で発生させられてしまうことに伴う脆弱性を利用した攻撃があるらしいが、どうして上位で発生するのよ、という部分が分からない。というか記事に書いてない。
こういうのって、通信時に上位プロセスのチェックとかってないのかな?
上記とは別ラインで、Googleが動いている模様。
<
グーグル、OpenSSLの新たなforkとして「BoringSSL」発表 - @IT
http://www.atmarkit.co.jp/ait/articles/1406/23/news117.html
グーグルがOpenSSLのforkを発表、独自の実装にOpenSSL側の変更をマージする体制を採る。OSSでの展開はしない方針だという。
米グーグルが、オープンソースのSSL/TLS実装「OpenSSL」から新プロジェクトの「BoringSSL」を派生させた。同社の研究者アダム・ラングリー氏が2014年6月20日、自身のブログ「ImperialViolet」で明らかにした。
ラングリー氏によると、グーグルでは「Heartbleed」と呼ばれる重大な脆弱性が発覚する以前からOpenSSLのコードを検証し、何年にもわたって多数のパッチを使用してきた。この中にはOpenSSLのメインレポジトリに採用されたものもある一方で、OpenSSLが保証するAPIやABIの安定性とかみ合わないものや、やや実験的過ぎるものも多かったという。
しかし、AndroidやChromeなどの製品でそうしたパッチのサブセットが必要になる中で、パッチの数は70を超え、複数のコードで横断的に管理する作業は手に負えなくなってきたという。
そこでモデルを切り替えて、OpenSSLの上に変更を積み重ねるのではなく、OpenSSLから変更を取り込む「BoringSSL」をスタートさせることにした。BoringSSLはまずChromiumで着手し、いずれAndroidやグーグル社内のプロジェクトにも採用したい意向だという。
BoringSSLのコードではAPIやABIの安定性は保証せず、OpenSSLの代替となるオープンソースプロジェクトを目指すつもりもないとラングリー氏は説明する。今後もOpenSSLの変更は取り入れ、バグを見つければ報告する方針。
OpenSSLの派生プロジェクトとしては、OpenBSD Foundationも4月に「LibreSSL」を発表しているが、BoringSSLではLibreSSLからの変更も取り入れやすくなるといい、LibreSSLがグーグルの変更を取り入れることも歓迎するとした。
OpenSSLなどのオープンソース技術を資金面で援助する「Core Infrastructure Initiative」や、OpenBSD Foundationへの資金提供は今後も続けると表明した。
>