The version of curl installed on the remote host is prior to 8.1.0. It is, therefore, affected by multiple vulnerabilities as referenced in the SSA:2023-137-01 advisory.

  - A use after free vulnerability exists in curl <v8.1.0 in the way libcurl offers a feature to verify an SSH     server's public key using a SHA 256 hash. When this check fails, libcurl would free the memory for the     fingerprint before it returns an error message containing the (now freed) hash. This flaw risks inserting     sensitive heap-based data into the error message that might be shown to users or otherwise get leaked and     revealed. (CVE-2023-28319)

  - A denial of service vulnerability exists in curl <v8.1.0 in the way libcurl provides several different     backends for resolving host names, selected at build time. If it is built to use the synchronous resolver,     it allows name resolves to time-out slow operations using `alarm()` and `siglongjmp()`. When doing this,     libcurl used a global buffer that was not mutex protected and a multi-threaded application might therefore     crash or otherwise misbehave. (CVE-2023-28320)

  - An improper certificate validation vulnerability exists in curl <v8.1.0 in the way it supports matching of     wildcard patterns when listed as Subject Alternative Name in TLS server certificates. curl can be built     to use its own name matching function for TLS rather than one provided by a TLS library. This private     wildcard matching function would match IDN (International Domain Name) hosts incorrectly and could as a     result accept patterns that otherwise should mismatch. IDN hostnames are converted to puny code before     used for certificate checks. Puny coded names always start with `xn--` and should not be allowed to     pattern match, but the wildcard check in curl could still check for `x*`, which would match even though     the IDN name most likely contained nothing even resembling an `x`. (CVE-2023-28321)

  - An information disclosure vulnerability exists in curl <v8.1.0 when doing HTTP(S) transfers, libcurl might     erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data to send, even when the     `CURLOPT_POSTFIELDS` option has been set, if the same handle previously wasused to issue a `PUT` request     which used that callback. This flaw may surprise the application and cause it to misbehave and either send     off the wrong data or use memory after free or similar in the second transfer. The problem exists in the     logic for a reused handle when it is (expected to be) changed from a PUT to a POST. (CVE-2023-28322)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

Detections

Analytics

Slackware Linux 14.0 / 14.1 / 14.2 / 15.0 / current curl Multiple Vulnerabilities (SSA:2023-137-01)

high Nessus Plugin ID 175989

Version 1.3