CVE-2022-3786 および CVE-2022-3602 は、OpenSSL 3.0 以降に影響するバッファオーバーフローの脆弱性で、それに対し11月1日、「OpenSSL 3.0.7」が公開されました。公式のアドバイザリはこちらでご覧いただけます。これら2つの脆弱性の深刻度はいずれもHigh（高）とされています。
どちらの脆弱性も、X.509 証明書を検証する際に、悪意を持って作成された電子メール アドレスの不適切な処理に起因します。アドバイザリによると、CVE-2022-3786 はサービス拒否 (DoS) を引き起こす可能性があり、CVE-2022-3602 は攻撃者が制御する 4 バイトを上書きすることにより、DoS またはリモートコード実行 (RCE) を引き起こす可能性があります。
目次
影響を受ける可能性のある対象
OpenSSL は、さまざまな Linux ディストリビューション、Docker コンテナー、node.js パッケージ、および同様のソフトウェアにプリインストールされているライブラリです。脆弱なすべてのインストールの完全なリストを作成することは不可能ですが、影響を受ける可能性のある主なディストリビューションを列挙したリソースは、こちら (Dutch NCSC)、Distro Watch、Docker アドバイザリ、およびNode.jsにあります。OpenSSL 3.0 はまだかなり新しい (2021 年 9 月 7 日に最初にリリースされた) ため、ほとんどの Linux ディストリビューションは、開発/ブリーディング エッジ リリース (Debian の「テスト」Bookworm など) または最後の安定版リリース (Ubuntu 22.04 および 22.10など) でのみ出荷しています。さらに、Node.js 18.x および 19.x は OpenSSL 3.0 を使用しますが、以前のバージョンの Node.js 14.x および 16.x は使用しません。
ネイティブ アプリケーションには、独自のバージョンの OpenSSL が同梱されている場合もあります。これは、次を検索して見つけることができます。
- Windows では libeay32.dll または ssleay32.dll
- libcrypto.dylib、MacOS の libssl.dylib
- Linux では、libcrypto.co.xy と libssl.so.xy (x と y はバージョン番号) を検索することもでき、この場合、ライブラリは共有ライブラリ フォルダー にインストールされる可能性がある。 (例: /usr/lib/x86_64-linux-gnu)
FIPS 140-2 準拠ソフトウェアの場合
FIPS 140-2 は、暗号化モジュールを検証するために NIST によって作成された標準と検証プロセスのセットです。このコンプライアンスは、米国およびカナダ政府の調達に必須であり、他のグローバル組織によっても要求される場合があります。そのため、OpenSSL FIPS Object Module 3.0 は OpenSSL 3.0 とのみ互換性があるというもう 1 つの要因が重要になる可能性があります。その前身である OpenSSL の古いバージョンと互換性のある OpenSSL FIPS オブジェクト モジュール 2.0 は、2022 年 1 月にサポートが終了しました。これは、FIPS 140-2 に準拠する必要があるソフトウェアが OpenSSL の新しいバージョンに移行し、以前のバージョンを「履歴リスト」に載せた可能性が高いことを意味します。 政府調達に必要な FIPS 140-2 コンプライアンスは現在、OpenSSL 3.0 を介してのみ達成可能であるため、近い将来、重要なコンテキスト (政府との契約) でより多くの採用が見られる可能性があるのは当然の状況です。
デプロイメントの統計
Akamai は、管理対象ネットワークの一部について調査を実施しましたが (ただし、サンプル サイズについては言及しませんでした)、その半分には、CVE-2022-3786 および CVE-2022-3602 に対して脆弱なバージョンの OpenSSL を使用するマシンが少なくとも 1 台ありました。これは、OpenSSL が脆弱な/影響のあるシナリオで使用されたことを必ずしも意味するものではありません。この高い比率は、わずか 16,000 台のサーバーが OpenSSL の脆弱なバージョンを公に使用しているのに対し、240k はまだ Heartbleed に対して脆弱であることを示すこれらの Shodan の統計によって概観することができます。最後に、この数は、まだ OpenSSL 1.x を使用している 210 万台を超えるサーバーに比べれば小さくなります。 (Shodanクエリはこちら)。
Trellix のお客様
現在 Trellix を使用している場合は、この更新されたナレッジ ベースの記事 ( FireEye 製品の KB ) を参照し、影響を受ける製品をご確認ください。検出と緩和の詳細については、Trellix Defenders ブログを引き続きご覧ください。
これらは次のHeartbleedなのか
そうではありません。CVE-2022-3602 の深刻度は「重大」から「高」に格下げされ、CVE-2022-3786は重大と見なされることはありませんでした。Heartbleed (これまでに OpenSSL に影響を与えた唯一の重大な脆弱性) は容易に悪用され、機密情報やサーバー メモリが漏洩する可能性があります。CVE-2022-3602 および CVE-2022-3786 はメモリ破損の脆弱性であり、すべてではないにしてもほとんどの関連するユース ケースでは、最新のセキュリティ緩和策により、これらの脆弱性が影響力のある方法で悪用される可能性が大幅に減少します (次のセクションで詳しく説明します)。 これが、OpenSSL のブログ投稿によると、深刻度の評価が下がった要因です。そうは言っても、CVE-2022-3602 と CVE-2022-3786 は依然として深刻度の高い脆弱性であり、遅かれ早かれ OpenSSL の最新バージョンにアップグレードすることをお勧めします。
技術的な詳細
OpenSSL バージョン 3.0.7 でパッチが適用された両方の脆弱性は、バッファ オーバーフローです。OpenSSL の開発者である Paul Dale による 3.0.6 と 3.0.7 の間の変更ログ (図 1) は、これらの問題を明らかにしています。
図 1: 変更の概要と CVE の説明
CVE-2022-3602
発表に見られるように、どちらの問題も従来のバッファ オーバーフローです。CVE-2022-3602 は、プレリリースのアナウンスでは「重大」と記載されていましたが、後に深刻度が「高」に格下げされ、攻撃者が 4バイトを制御できるようになります。攻撃者が悪意のある電子メールアドレス フィールドを含む証明書を提供すると、バッファがオーバーランします。これに関する問題は、この脆弱性を悪用することを意図した電子メールアドレスを含む悪意のある証明書が、最初に認証局 (CA) によって署名されなければならないことです。つまり、攻撃者は最初に悪意のある証明書を事前に署名するためにソーシャル エンジニアリングを行うか、信頼できる発行者につながる信頼チェーンを持たずにサーバーが無効な証明書を処理し続けることを期待する必要があります。
この脆弱性のパッチは、単純なコーディングのミスがいかに大きな影響を与えるかを示す好例です。図 2 からわかるように、この脆弱性に対するパッチは単に「>」演算子に「=」を追加するだけで、1 つの問題でオフを効果的に排除していました。
図 2: CVE-2022-3502 パッチ
開示発表と重大度の引き下げ後に、この脆弱性を利用しようとする攻撃者に対して機能する 2 つの軽減要素があります。この脆弱性の現在の状態では、「コードの実行につながる可能性のある有効なエクスプロイトは認識しておらず、このアドバイザリのリリース時 (11 月 1 日) の時点で、この問題が悪用されたという証拠はありません。 、2022年）」。さらに、スタック カナリアなどのスタック保護やその他のスタックベースのバッファ オーバーフロー保護がデフォルトで有効になっていることが多く、この脆弱性の影響がさらに制限されます。
CVE-2022-3786
これは別のバッファ オーバーフローの脆弱性ですが、攻撃者が「.」のみで任意のバイト数を上書きできるという独自の特性があります。(ピリオド) 文字。任意のバイト数を書き込むことができれば、攻撃者に大きな利益をもたらす可能性がありますが、メモリに 46 の値しか書き込めないというのはあまり役に立ちません。さらに、この脆弱性は CVE-2022-3602 と同じ制約によって制限されます。つまり、この脆弱性を悪用するために作成された悪意のある証明書は、CA によって署名されているか、サーバーが無効な信頼チェーンのエラーを無視する必要があります。
CVE-2022-3786 の修正は、以前の脆弱性のように「=」記号を追加するほど単純ではありませんが、OpenSSL 開発者は、電子メール アドレスの解析に使用されるロジックを修正することで問題を修正することができました。
両方の脆弱性について注意すべきことの 1 つは、サーバーがユーザー提供の証明書を認証しているときに悪意のあるクライアントによって、または悪意のあるサーバーによって被害者が接続されることによってトリガーされる可能性があることです。攻撃者がすべての既存の軽減策をうまく回避した場合、両方の脆弱性の結果として DoS が発生し、CVE-2022-3602 の RCE が発生する可能性もあります。
結論
CVE-2022-3602 の当初の深刻度は懸念材料でしたが、現在は「高」に格下げされており、これまでのOpenSSLの脆弱性の中でも目立つものではなくなりました。また、影響を受けるのは OpenSSL のバージョン 3.0 以降のみであり、これは OpenSSL の全ユーザー ベースのほんの一部であることも幸いです。さらに、この記事の執筆時点では、この脆弱性の悪用は確認されていません。パニックにならず、いつものように、OS、脆弱なライブラリの内部使用、およびサードパーティ製ソフトウェアによるアップデートに注意を払い、迅速に更新してください。Trellix は状況を監視し続け、何か新しいことが明らかになった場合はこの投稿を更新します。
本記事およびここに含まれる情報は、啓蒙目的およびTrellixの顧客の利便性のみを目的としてコンピュータ セキュリティの研究について説明しています。Trellixは、脆弱性合理的開示ポリシーに基づいて調査を実施しています。記載されている活動の一部または全部を再現する試みについては、ユーザーの責任において行われるものとし、Trellixおよびその関連会社はいかなる責任も負わないものとします。
※本ページの内容は2022年11月1日（US時間）更新の以下のTrellix Storiesの内容です。
原文：OpenSSL 3.0 Vulnerabilities: CVE 2022-3786 and CVE 2022-3602
著者：Philippe Laulheret, Charles McFarland, Sam Quinn