libcurl exists some bugs that leak authentication data to third parties

According to securityaffairs, on January 25, the researchers found that the client URL transfer library libcurl is being affected by some flaws. One of them is largely related to the way HTTP headers handle custom headers, potentially causing authentication data to leak to third parties. In addition, an “outbounds read in code handling HTTP/2 trailers” vulnerability also caused some distress to libcurl.

Handle custom headers in HTTP requests

When asked to send a custom header in an HTTP request, libcurl first sends the set of headers to the host in the original URL. But if it is required to follow the redirect and return a 30X HTTP response code, libcurl will send it to the host mentioned by the URL in the response header.

“libcurl 7.1 through 7.57.0 might accidentally leak authentication data to third parties. When asked to send custom headers in its HTTP requests, libcurl will send that set of headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the `Location:` response header value. Sending the same set of headers to subsequest hosts is in particular a problem for applications that pass on custom `Authorization:` headers, as this header often contains privacy sensitive information or data that could allow others to impersonate the libcurl-using client’s request.”

Researchers said sending the same set of headers to sub-sequence hosts is a special issue for applications that pass custom Authorization. Because this set of headers usually contains sensitive information and data, it can be abused by attackers to mimic libcurl-using client requests.

This vulnerability was tracked as CVE-2018-1000007, which appeared in 1999. The current affected version of libcurl 7.1 to 7.57.0, the subsequent version (7.58.0) was not affected.

Outbounds read in code handling HTTP/2 trailers

The data is read out of bounds on an access, resulting in a crash or (too big) data being passed to the libcurl callback. If someone’s service can respond to or use the trailer header, it is likely to cause the denial of service or information disclosure.

libcurl 7.49.0 to and including 7.57.0 contains an out bounds read in code handling HTTP/2 trailers. It was reported (https://github.com/curl/curl/pull/2231) that reading an HTTP/2 trailer could mess up future trailers since the stored size was one byte less than required. The problem is that the code that creates HTTP/1-like headers from the HTTP/2 trailer data once appended a string like `:` to the target buffer, while this was recently changed to `: ` (a space was added after the colon) but the following math wasn’t updated correspondingly. When accessed, the data is read out of bounds and causes either a crash or that the (too large) data gets passed to client write. This could lead to a denial-of-service situation or an information disclosure if someone has a service that echoes back or uses the trailers for something.

The vulnerability was tracked as CVE-2018-1000005 affecting versions of libcurl from 7.49.0 to 7.57.0. Fortunately, the current researchers did not find this loophole to be exploited in the wild.

Source: SecurityAffairs, redhat