リモートホストにインストールされているcurlのバージョンは、7.79.1-1より前です。したがって、ALAS2-2021-1724のアドバイザリに記載されている複数の脆弱性の影響を受けます。

  - MQTTサーバーにデータを送信する際、libcurl <= 7.73.0および7.78.0は、状況によっては、すでに解放されているメモリ領域へのポインターを誤って保持し、その後の呼び出しでそれを再び使用してデータを送信し、*再度*解放する可能性があります。 (CVE-2021-22945)

  -ユーザーは、IMAP、POP3またはFTPサーバーと対話する際、にcurl >= 7.20.0および <= 7.78.0を指示して、TLSへの正常なアップグレードを要求することができます (コマンドラインの「--ssl-reqd」または「CURLOPT_USE_SSL」を「CURLUSESSL_CONTROL」もしくは「CURLUSESSL_ALL」withlibcurlに設定) 。サーバーが適切に細工された、しかしながら完全に正当な応答を返す場合、この要件はバイパスされる可能性があります。この欠陥により、curlはサイレントに操作を続行します。
    ** TLSなし**指示と期待に反し、ネットワーク上で機密データを平文で漏洩する可能性があります。(CVE-2021-22946)

  -curl> = 7.20.0および<= 7.78.0がIMAPまたはPOP3サーバーに接続し、STARTTLSを使用してデータを取得し、TLSセキュリティにアップグレードする場合、サーバーはそのcurlキャッシュにすぐに応答し、複数の応答を返すことができます。
    その後、curlはTLSにアップグレードしますが、キャッシュされた応答のキュー内をフラッシュせず、TLSハンドシェイクが認証されるかのように、 TLSハンドシェイク*以前に*取得した応答を使用し、信頼し続けます。この欠陥を利用すると、中間攻撃者が、最初に偽の応答を注入し、次に正当なサーバーからのTLSトラフィックをパススルーし、curlをだましてユーザーにデータを返送させます。ユーザーは攻撃者が注入したデータはTLSで保護されたサーバーからのものであると考えます。(CVE-2021-22947)

Nessus はこの問題をテストしておらず、代わりにアプリケーションの自己報告されたバージョン番号にのみ依存しています。

リモートホストは、macOS/Mac OS X を実行していますが、バージョン 12.3 Monterey より前の 12.x です。そのため、以下を含む複数の脆弱性による影響を受けます:
  - メモリ管理を改善することで、メモリ解放後使用 (Use After Free) の問題に対処しました。悪用に成功すると、カーネル権限で任意コード実行が行われる可能性があります。(CVE-2022-22614) 

  - 状態管理を改善することで、ロジックの問題に対処しました。悪用に成功すると、権限昇格が行われる可能性があります。(CVE-2022-22632)

  - null ポインターデリファレンスは、検証を改善することにより、対処されました。悪用に成功すると、サービス拒否状態が発生する可能性があります。(CVE-2022-22638)

Nessus はこれらの問題をテストしておらず、代わりにオペレーティングシステムが自己報告するバージョン番号にのみ頼っています。

リモートの Debian 11 ホストには、dsa-5197 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

  - libcurl で「CURLOPT_TELNETOPTIONS」として知られる「-t」コマンドラインオプションを使用して variable=content ペアを TELNET サーバーに送信するとき、curl 7.7〜7.76.1 は情報漏洩の影響を受けます。NEW_ENV変数を送信するためのオプションパーサーの欠陥により、libcurlがスタックベースのバッファからの初期化されていないデータをサーバーに渡し、平文ネットワークプロトコルを使用しているサーバーに機密の内部情報が漏洩する可能性があります。 (CVE-2021-22898)

  -libcurl は、以前に使用された接続の 1 つがセットアップと一致する場合、それらの接続を接続プールに保持して、subsequenttransfers が再利用します。ロジック内のエラーにより、構成マッチング関数は「issuercert」を考慮せず、関係するパスを*大文字と小文字を区別せず*に比較していました。これにより libcurl が不適切な接続を再利用することにつながる可能性があります。ファイルパスは、すべてというわけではありませんし、使用するファイルシステムによっても異なりますが、多くのシステムで大文字と小文字が区別されているか、区別することが可能です。比較には、転送の際にサーバー証明書の検証方法を評価するために設定できる「発行者証明書」も含まれていませんでした。(CVE-2021-22924)

  - MQTT サーバーにデータを送信する際、libcurl <= 7.73.0 および 7.78.0 は、状況によっては、すでに解放されているメモリ領域へのポインターを誤って保持し、その後の呼び出しでそれを再び使用してデータを送信し、*再度*解放する可能性があります。(CVE-2021-22945)

  -ユーザーは、IMAP、POP3またはFTPサーバーと対話する際、にcurl >= 7.20.0および <= 7.78.0を指示して、TLSへの正常なアップグレードを要求することができます (コマンドラインの「--ssl-reqd」または「CURLOPT_USE_SSL」を「CURLUSESSL_CONTROL」もしくは「CURLUSESSL_ALL」withlibcurlに設定) 。サーバーが適切に細工された、しかしながら完全に正当な応答を返す場合、この要件はバイパスされる可能性があります。この欠陥により、curlはサイレントに操作を続行します。
    ** TLSなし**指示と期待に反し、ネットワーク上で機密データを平文で漏洩する可能性があります。(CVE-2021-22946)

  -curl> = 7.20.0および<= 7.78.0がIMAPまたはPOP3サーバーに接続し、STARTTLSを使用してデータを取得し、TLSセキュリティにアップグレードする場合、サーバーはそのcurlキャッシュにすぐに応答し、複数の応答を返すことができます。
    その後、curl は TLS にアップグレードしますが、キャッシュされた応答のキュー内をフラッシュせず、TLS ハンドシェイクが認証されるかのように、TLS ハンドシェイク*以前に*取得した応答を使用し、信頼し続けます。この欠陥を利用すると、中間攻撃者が、最初に偽の応答を注入し、次に正当なサーバーからの TLS トラフィックをパススルーし、curl をだましてユーザーにデータを返送させます。ユーザーは攻撃者が注入したデータは TLS で保護されたサーバーからのものであると考えます。(CVE-2021-22947)

  - 不適切な認証の脆弱性が curl 7.33.0 から 7.82.0 までに存在します。これにより、この転送に設定されたものと同じ認証情報で認証されていることを適切に確認せずに、OAUTH2 認証済み接続を再利用することが可能です。これは SASL 有効化プロトコルに影響を与えます。SMPTP (S)、IMAP (S)、POP3 (S) および LDAP (S) (openldapのみ)。(CVE-2022-22576)

  -curl 4.9から curl 7.82.0に、認証情報の保護が不十分である脆弱性が存在します。これにより、認証で使用される HTTP(S) リダイレクトをフォローする場合、攻撃者は認証情報を抽出し、異なるプロトコルまたはポート番号に存在する他のサービスへ認証情報を漏洩する可能性があります。
    (CVE-2022-27774)

  - curl 7.65.0から 7.82.0 に情報漏洩の脆弱性が存在します。この脆弱性は、接続プールにあるが異なるゾーン ID を持つ IPv6 アドレスを使用することによるもので、代わりに接続を再利用する可能性があります。(CVE-2022-27775)

  - curl 7.83.0で修正された認証情報の保護が不十分であるため、同じホストではあるものの、別のポート番号への HTTP リダイレクトの認証または cookie ヘッダーデータが漏洩する可能性があります。(CVE-2022-27776)

  - libcurl は「CURLOPT_CERTINFO」オプションを提供し、アプリケーションがサーバーの証明書チェーンに関する詳細をリクエストできるようにします。誤った関数により、その情報を取得しようと試みる場合、悪意のあるサーバーが NSS で構築された libcurl をスタックさせる可能性があります。
    (CVE-2022-27781)

  - libcurl は TLS または SSH 関連のオプションが変更されているが再利用を禁止している場合でも、以前に作成された接続を再利用します。libcurl は接続プール中の 1 つが設定と一致した場合、接続プール内の subsequenttransfers に対して以前に使用された接続を再利用するために維持します。ただし、いくつかの TLS および SSH 設定は、構成の一致チェックから除外されているため、簡単に一致させることができません。(CVE-2022-27782)

  - 悪意のあるサーバーが過剰な量のcurl に対する HTTP 応答の「Set-Cookie:」ヘッダーを提供し、curl < 7.84.0はそれらすべてを保存します。十分に大量の (大きな) Cookie により、この後続の HTTP リクエスト、または Cookie が一致する他のサーバーは、異常に大きなリクエスト (1048576 バイト) の送信を回避するために curl が内部で使用する閾値よりも大きなリクエストを作成し、エラーを返します。この拒否状態は、同じ Cookie が保持され、一致しており、期限が切れていない限り維持される可能性があります。Cookie マッチングルールにより、「foo.example.com」上のサーバーは、「bar.example.com」にも一致する Cookie を設定できるため、シスターサーバーがこのメソッドを使用して、同一のセカンドレベルドメイン上の兄弟サイトに対してサービス拒否を効果的に引き起こすことが可能です。(CVE-2022-32205)

  - curl < 7.84.0は、連鎖された HTTP 圧縮アルゴリズムをサポートします。これは、サーバー応答が複数回、場合によっては異なるアルゴリズムで、圧縮される可能性があることを意味します。この解凍チェーンの受け入れ可能なリンクの数が無制限であったため、悪意のあるサーバーが事実上無制限の数の圧縮ステップを挿入することが可能でした。このような解凍チェーンを使用すると、malloc ボムが発生し、curl が割り当てられたヒープメモリを大量に消費したり、メモリエラーを試したり戻したりする可能性があります。(CVE-2022-32206)

  - curl < 7.84.0が Cookie、alt-svc、hsts のデータをローカルファイルに保存するとき、一時的な名前から最終的なターゲットファイル名への名前変更で操作をファイナライゼーションすることで、操作をアトミックにします。この名前変更操作で、偶発的に、ターゲットファイルの権限を *拡大* し、意図したよりも多くのユーザーが更新済みファイルにアクセスできるようになる可能性があります。(CVE-2022-32207)

  - curl < 7.84.0が krb5 によって保護された FTP 転送を行う場合、メッセージ検証の失敗を不適切に処理します。
    この欠陥により、中間者攻撃が気付かれずに、データがクライアントに注入される可能性さえあります。(CVE-2022-32208)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションの自己報告されたバージョン番号にのみ依存しています。

リモートホストにインストールされているcurlのバージョンは、7.79.0より前です。したがって、SSA：2021-258-01のアドバイザリに記載されている複数の脆弱性の影響を受けます。

  -curl> = 7.20.0および<= 7.78.0がIMAPまたはPOP3サーバーに接続し、STARTTLSを使用してデータを取得し、TLSセキュリティにアップグレードする場合、サーバーはそのcurlキャッシュにすぐに応答し、複数の応答を返すことができます。
    その後、curlはTLSにアップグレードしますが、キャッシュされた応答のキュー内をフラッシュせず、TLSハンドシェイクが認証されるかのように、 TLSハンドシェイク*以前に*取得した応答を使用し、信頼し続けます。この欠陥を利用すると、中間攻撃者が、最初に偽の応答を注入し、次に正当なサーバーからのTLSトラフィックをパススルーし、curlをだましてユーザーにデータを返送させます。ユーザーは攻撃者が注入したデータはTLSで保護されたサーバーからのものであると考えます。 (CVE-2021-22947)

  - MQTTサーバーにデータを送信する際、libcurl <= 7.73.0および7.78.0は、状況によっては、すでに解放されているメモリ領域へのポインターを誤って保持し、その後の呼び出しでそれを再び使用してデータを送信し、*再度*解放する可能性があります。 (CVE-2021-22945)

  -ユーザーは、IMAP、POP3またはFTPサーバーと対話する際、にcurl >= 7.20.0および <= 7.78.0を指示して、TLSへの正常なアップグレードを要求することができます (コマンドラインの「--ssl-reqd」または「CURLOPT_USE_SSL」を「CURLUSESSL_CONTROL」もしくは「CURLUSESSL_ALL」withlibcurlに設定) 。サーバーが適切に細工された、しかしながら完全に正当な応答を返す場合、この要件はバイパスされる可能性があります。この欠陥により、curlはサイレントに操作を続行します。
    ** TLSなし**指示と期待に反し、ネットワーク上で機密データを平文で漏洩する可能性があります。 (CVE-2021-22946)

Nessusはこの問題をテストしておらず、代わりにアプリケーションの自己報告されたバージョン番号にのみ依存しています。

リモートの CentOS Linux 9 ホストに、curl-7.76.1-12.el9 ビルド変更ログに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - MQTTサーバーにデータを送信する際、libcurl <= 7.73.0および7.78.0は、状況によっては、すでに解放されているメモリ領域へのポインターを誤って保持し、その後の呼び出しでそれを再び使用してデータを送信し、*再度*解放する可能性があります。（CVE-2021-22945）

  - ユーザーは、IMAP、POP3 または FTP サーバーと対話する際に curl >= 7.20.0 および <= 7.78.0 を指示して、TLS への正常なアップグレードを要求することができます (コマンドラインの「--ssl-reqd」または「CURLOPT_USE_SSL」を「CURLUSESSL_CONTROL」もしくは「CURLUSESSL_ALL」withlibcurl に設定)。サーバーが適切に細工された、しかしながら完全に正当な応答を返す場合、この要件はバイパスされる可能性があります。この欠陥により、curlはサイレントに操作を続行します。
    ** TLS なし**指示と期待に反し、ネットワーク上で機密データを平文で漏洩する可能性があります。(CVE-2021-22946)

  -curl> = 7.20.0 および <= 7.78.0 が IMAP または POP3 サーバーに接続し、STARTTLS を使用してデータを取得し、TLS セキュリティにアップグレードする場合、サーバーはその curl キャッシュにすぐに応答し、複数の応答を返すことができます。
    その後、curl は TLS にアップグレードしますが、キャッシュされた応答のキュー内をフラッシュせず、TLS ハンドシェイクが認証されるかのように、TLS ハンドシェイク*以前に*取得した応答を使用し、信頼し続けます。この欠陥を利用すると、中間攻撃者が、最初に偽の応答を注入し、次に正当なサーバーからの TLS トラフィックをパススルーし、curl をだましてユーザーにデータを返送させます。ユーザーは攻撃者が注入したデータは TLS で保護されたサーバーからのものであると考えます。(CVE-2021-22947)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

リモートのUbuntu 18.04 LTS/20.04 LTS/21.04ホストには、USN-5079-1のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

  - MQTTサーバーにデータを送信する際、libcurl <= 7.73.0および7.78.0は、状況によっては、すでに解放されているメモリ領域へのポインターを誤って保持し、その後の呼び出しでそれを再び使用してデータを送信し、*再度*解放する可能性があります。（CVE-2021-22945）

  -ユーザーは、IMAP、POP3またはFTPサーバーと対話する際、にcurl >= 7.20.0および <= 7.78.0を指示して、TLSへの正常なアップグレードを要求することができます (コマンドラインの「--ssl-reqd」または「CURLOPT_USE_SSL」を「CURLUSESSL_CONTROL」もしくは「CURLUSESSL_ALL」withlibcurlに設定) 。サーバーが適切に細工された、しかしながら完全に正当な応答を返す場合、この要件はバイパスされる可能性があります。この欠陥により、curlはサイレントに操作を続行します。
    ** TLSなし**指示と期待に反し、ネットワーク上で機密データを平文で漏洩する可能性があります。(CVE-2021-22946)

  -curl> = 7.20.0および<= 7.78.0がIMAPまたはPOP3サーバーに接続し、STARTTLSを使用してデータを取得し、TLSセキュリティにアップグレードする場合、サーバーはそのcurlキャッシュにすぐに応答し、複数の応答を返すことができます。
    その後、curlはTLSにアップグレードしますが、キャッシュされた応答のキュー内をフラッシュせず、TLSハンドシェイクが認証されるかのように、 TLSハンドシェイク*以前に*取得した応答を使用し、信頼し続けます。この欠陥を利用すると、中間攻撃者が、最初に偽の応答を注入し、次に正当なサーバーからのTLSトラフィックをパススルーし、curlをだましてユーザーにデータを返送させます。ユーザーは攻撃者が注入したデータはTLSで保護されたサーバーからのものであると考えます。(CVE-2021-22947)

Nessusはこの問題をテストしておらず、代わりにアプリケーションの自己報告されたバージョン番号にのみ依存しています。

cURLプロジェクトによる報告：

- MQTT送信におけるUAFおよび二重解放（CVE-2021-22945）

- プロトコルのダウングレードに必要なTLSのバイパス（CVE-2021-22946）

- MITMによるSTARTTLSプロトコルインジェクション（CVE-2021-22945）

ID	名前	製品	ファミリー	公開日	更新日	深刻度
155980	Amazon Linux 2：curl (ALAS-2021-1724)	Nessus	Amazon Linux Local Security Checks	2021/12/10	2023/11/22	critical
159106	macOS 12.x < 12.3 (HT213183)	Nessus	MacOS X Local Security Checks	2022/3/21	2023/11/3	critical
163681	Debian DSA-5197-1: curl - セキュリティ更新	Nessus	Debian Local Security Checks	2022/8/2	2023/10/17	critical
153430	Slackware Linux 14.0/14.1/14.2/最新版curlの複数の脆弱性 (SSA：2021-258-01)	Nessus	Slackware Local Security Checks	2021/9/16	2023/11/30	critical
191350	CentOS 9 : curl-7.76.1-12.el9	Nessus	CentOS Local Security Checks	2024/2/29	2024/4/26	critical
153407	Ubuntu 18.04 LTS / 20.04 LTS : curl の脆弱性 (USN-5079-1)	Nessus	Ubuntu Local Security Checks	2021/9/15	2023/10/16	critical
153812	FreeBSD：cURL -- 複数の脆弱性（c9221ec9-17a2-11ec-b335-d4c9ef517024）	Nessus	FreeBSD Local Security Checks	2021/10/1	2023/11/29	critical

検出

プラグインの検索

critical

critical

critical

critical

critical

critical

critical