OpenSSL 3.0.8 で対応された深刻度「High（高）」のCVE-2023-0286とは

脅威情報
2023.2.10

1 背景
2 CVE-2023-0286の概要
3 今回は本当にオオカミがいるのか
4 対処法

背景

OpenSSLが、「深刻度：高」と評価された2つのバッファオーバーフロー脆弱性によって、広く監視の対象となったのは、つい昨日のことのように感じられます。幸いなことに、どちらの脆弱性も技術的には素晴らしいものでしたが、脅威の領域が限られていたことと、最新のシステムでメモリ破壊を悪用する試みを複雑にする様々な緩和要因が重なったため、現実世界ではそれほど影響がないであろうことが判明しました。

それからわずか数カ月、私たちは再び同じ苦境に立たされているようです。OpenSSLの最新のセキュリティアドバイザリでは、最新リリース（3.0.8）で修正されたさまざまな脆弱性が列挙されており、そのうちのいくつかは11月にすでに報告されていたものです。リストのトップはCVE-2023-0286で、勧告の中で唯一「深刻度：高」にランクされている脆弱性です。この脆弱性は、CVE-2022-3602やCVE-2022-3786が悪用される可能性がそれほど高くはないであろうことが判明する前に多くの人が疑ったように、実際に次のHeartbleed*となるのでしょうか？

CVE-2023-0286の概要

簡単に言うと、CVE-2023-0286 は、OpenSSLがX.400 アドレスを含むX.509 GeneralNamesを処理するときに実行される、Type Confusion（型の取り違え・混同）の脆弱性です。証明書処理で使用されるデータ形式に精通していない人のために、X.400アドレスは基本的にメールアドレスですが、オンラインデータ用であり、GeneralName はIPアドレスからDNS名、さらにはX.400アドレスまで、あらゆるものを参照できる包括的なデータ型であることを知っておく必要があります。X.400とX.509は、これらの用語を定義する異なる規格であり、公開鍵証明書やデジタル署名などの一般的な暗号化サービスで利用される他の多くの用語も定義しています。

GeneralName にはさまざまなデータが含まれる可能性があるため、OpenSSL は GeneralName を処理する際に、それが正しく処理されるようにチェックを行っています。残念ながら、OpenSSL が X.400 アドレスを含む GeneralName を処理する際、ASN1_STRINGの代わりにASN1_TYPEを使用して、そのアドレスを誤ったデータ型で保存するため、典型的な型の混乱の脆弱性が発生します。具体的には、OpenSSL が証明書失効リスト (CRL)を処理するときに、この欠陥が露呈します。このプロセス中に、C関数のmemcmpを使用して、2つのX.400アドレスを比較することが可能です。ASN1_TYPE と ASN1_STRING 構造体の間でメモリレイアウトが異なるため、攻撃者は memcmp に供給するメモリアドレスを任意に指定することが可能です。これにより、攻撃者が指定したメモリと比較され、メモリ内容の漏洩やサービス拒否を引き起こす可能性があります。

今回は本当にオオカミがいるのか

一言で言えば、「いいえ」です。この脆弱性には、攻撃者にとって有用性を制限する多くの前提条件と緩和要因があります。

まず、脆弱なコードパスに到達できるのは、CRL チェック中（サーバーが提供された証明書を CRL と照合して、それが失効していないことを確認するとき）だけで、そのためには X509_V_FLAG_CRL_CHECK フラグによって CRL チェックを有効化する必要があります。

これだけでも珍しいことではありませんが、2 番目の要件は、 memcmp関数に提供される 2 つの GeneralNames の両方に、X.400アドレスの形式の CRL 配布ポイントが含まれていることです。CRL は無効になった証明書を定義しますが、その配布ポイントは最初に証明書を見つける場所 (通常は LDAP ディレクトリまたは Web サーバーのアドレスの形式) を定義します。重要なのは、この場所が X.400 アドレスとしてエンコードされていることは非常に稀であるということです。つまり、このベクトルは、攻撃者が証明書と CRL の両方の入力を制御する場合にのみ実行可能です。しかし、サードパーティのCRLを利用し、ネットワーク経由で取得するように設定されたアプリケーションも珍しいため、これは単にあり得ないシナリオを別のシナリオに置き換えただけです。

攻撃者がこれらの条件をすべて満たしたとしても、攻撃を実行するには、脆弱なアプリケーションが証明書とCRLをリアルタイムでダウンロードする必要があるため、別の課題が発生します。Red Hatによると、これは「TLS 接続の確立中に別の HTTP リクエストを意味するため、ほとんど不可能」です。最後に、データの流出は確かに可能ですが、攻撃者が取得する唯一のフィードバックは推測が正しいかどうか (そして、彼らの推測が間違っていると判断するまでにサーバーが要した時間、ただしこれは信頼性が低い）なので、任意の読み取りプリミティブとは程遠いものです。簡単に言えば、これは非常に遅いデータ抽出方法です。おそらく、このような攻撃の最も影響力のある応用例は、「BEGIN RSA PRIVATE KEY」などの既知のキーワードまたはプレフィックスを持つ、小さいながらも機密性の高いデータを見つけることでしょう。

対処法

これはHeartbleedではありませんが、インターネットを介したデータ流出の影響はほとんどの組織にとって重大なリスクであるため、パッチを適用することを強くお勧めします。OpenSSL のアドバイザリは、OpenSSL バージョン 1.02、1.1.1、および 3.0 はすべて脆弱であると述べているため、組織でこれらのいずれかを実行している場合は、それぞれバージョン 1.0.2zg、1.1.1t、および 3.0.8 に更新する必要があります。

この問題は、CRLのコンテキストでASN1_TYPE構造の誤った使用を正しいASN1_STRING構造に変更することにより、OpenSSLで修正されました。