したがって、ALAS2023-2023-083 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

  - 不適切な認証の脆弱性が 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 はトップレベルドメイン (TLD) に対して cookies が設定することを許可します。curl に cookies を受け取り、送信するよう指示することができます。curl の cookie エンジンは [Public Suffix List](https://publicsuffix.org/)awareness を使用して、または使用せずに、構築することが可能です。PSL サポートが提供されない場合、少なくとも TLD にクッキーが設定されるのを防ぐために、より初歩的なチェックが存在します。URL のホスト名が末尾にドットを使用している場合、このチェックは不具合を起こしました。これにより、任意のサイトがクッキーを設定し、別の無関係のサイトやドメインにそれを送信することが許容されます。(CVE-2022-27779)

  - curl URL パーサーは、URL のホスト名部分をデコードする際に、「/」などのパーセントエンコードされた URL セパレーターを誤って受け入れ、後で取得する際に、間違ったホスト名を使用する *異なる* URL にします。たとえば、「http://example.com%2F127.0.0.1/` のような URL は、パーサーによって許可され、「http://example.com/127.0.0.1/` に置き換えられます。この欠陥は、フィルターやチェックなどを回避するために使用される可能性があります。
    (CVE-2022-27780)

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

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

  - HSTS サポートを使用すると、URL で HTTP が提供されている場合でも、安全でない平文 HTTP ステップを使用する代わりに HTTPS を直接使用するように curl に指示できます。HSTS キャッシュを構築する際に、指定された URL のホスト名がドットを使用せずに、それを使用している場合、このメカニズムがバイパスされる可能性があります。または逆に
    - HSTS キャッシュに末尾のドットを配置し、URL の末尾にドットを使用しない*。
    (CVE-2022-30115)

  - 悪意のあるサーバーが過剰な量の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)

  - HTTP(S) 転送を行う際に、libcurl は誤ってリード コールバック (「CURLOPT_READFUNCTION」) を使用して送信するデータを求める場合がありました。以前に同じハンドルがそのコールバックを使用する「PUT」リクエストを発行するために使用されていた場合は、「CURLOPT_POSTFIELDS」オプションが設定されている場合でもそうなりました。この欠陥により、アプリケーションが予期しない動作をし、不適切なデータを送信したり、後続の「POST」リクエストでメモリ解放後使用または類似のメモリ使用を引き起こしたりする可能性があります。PUT から POST に変更されたときに、再利用されたハンドルのロジックに問題があります。(CVE-2022-32221)

  - HTTP(S) サーバーからクッキーを取得して解析するために curl が使用される場合、制御コードを使用してクッキーが受け入れられ、後で HTTP サーバーに返されると、サーバーが 400 応答を返します。
    asister サイトがすべての sibling へのサービスを拒否することを効果的に許可します。(CVE-2022-35252)

  - curl は認証情報の「.netrc」ファイルを解析するように指示される可能性があります。もし、そのファイルが 4095 個の非空白文字が連続する行で終わり、改行がない場合、curl はまずスタックベースのバッファの終端を読み、読み込みが成功したら、境界を越えて 0 バイトを書き込みます。ほとんどの場合、セグメンテーションエラーなどが発生しますが、状況によっては異なる結果になることもあります。悪意のあるユーザーが、カスタム netrc ファイルをアプリケーションに提供したり、その内容に影響を与えたりする場合、この欠陥はサービス拒否として利用される可能性があります。(CVE-2022-35260)

  - 7.86.0より前の curl には二重解放があります。curl が HTTP(S) 以外の URL との転送に HTTP プロキシを使用するように指示された場合、プロキシに CONNECT リクエストを発行することでリモートサーバーへの接続を設定し、残りのプロトコルをトンネルします。HTTP プロキシがこのリクエストを拒否し (HTTP プロキシは、HTTPS の 443 のような特定のポート番号への送信接続のみを許可することがよくあります)、代わりに非 200 ステータスコードをクライアントに返します。エラー / クリーンアップ処理の欠陥により、転送のための URL で次のスキームの 1 つが使用された場合、curl で二重解放が発生する可能性があります: dict、gopher、gophers、ldap、ldaps、rtmp、rtmps、telnet。影響を受ける最も古いバージョンは 7.77.0です。(CVE-2022-42915)

  - 7.86.0より前の curl では、HSTS チェックがバイパスされて、HTTP に留まる可能性があります。HSTS サポートを使用すると、HTTP が URL で提供されている場合でも、curl に (安全でない平文 HTTP ステップを使用する代わりに) 直接 HTTPS を使用するよう指示することができます。特定の URL のホスト名が IDN 変換の一部として ASCII の対応文字列で置換される IDN 文字を使用する場合、このメカニズムはバイパスされる可能性があります。例えば、U+002E(.) の一般的な ASCII を完全に停止する代わりに、文字 UTF-8 U + 3002 (IDEOGRAPHIC FULL STOP) を使用します。
    影響を受ける最も古いバージョンは 7.77.02021-05-26 です。(CVE-2022-42916)

  curl <7.87.0 の HSTS チェックに脆弱性が存在し、バイパスして HTTP を使い続けさせる可能性があります。
    HSTS サポートを使用すると、HTTP が URL で提供されている場合でも、安全でない平文 HTTP ステップを使用する代わりに HTTPS を使用するよう curl に指示できます。ただし、指定された URL のホスト名が、IDN 変換の一部として ASCII の文字列に置き換えられる IDN 文字を最初に使用する場合、HSTS メカニズムがバイパスされる可能性があります。一般的な ASCII フルストップ (U+002E) `.` の代わりに UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) 文字を使用するのと同じです。その後のリクエストでは、HSTS 状態が検出されず、平文転送が行われます。IDN エンコードされた情報を保存しますが、IDN デコードされた情報を検索するためです。(CVE-2022-43551)

  - curl <7.87.0 にメモリ解放後使用 (UseAfter Free) の脆弱性が存在します。Curl が、HTTP プロキシを介して、サポートするほぼすべてのプロトコルをトンネリングするように要求される可能性があります。HTTP プロキシは、このようなトンネル操作を拒否できます (多くの場合、拒否できます)。
    特定のプロトコル SMB または TELNET のトンネリングが拒否されると、curl は、転送シャットダウンコードパスで、解放された後にヒープに割り当てられた構造体を使用します。(CVE-2022-43552)

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

検出

Amazon Linux 2023 : curl、curl-minimal、libcurl (ALAS2023-2023-083)

critical Nessus プラグイン ID 173171

バージョン 1.6