libcurl has had auth leak bug since 'the first commit we recorded'

Fixed in 7.58.0

If you use libcurl, the command line tool and library for transferring data with URLs, get ready to patch. The tool has a pair of problems, one of which is an authentication leak.

This advisory says the library can leak authentication data to third parties because of how it handles custom headers in HTTP requests.

“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”, the advisory states.

Applications that pass on custom authorisation headers could therefore leak credentials or “data that could allow others to impersonate the libcurl-using client's request”.

CVE-2018-1000007 has been present since “before curl 6.0”, the advisory states – meaning it goes back to before September 1999: Indeed, the advisory 'fesses up that “It existed in the first commit we have recorded in the project”.

Users need to upgrade to curl 7.58.0, and there's a warning of a change of behaviour to close the bug. If you need to pass a header to other hosts, curl needs a specific permission to do so, using a --location-trusted flag.

The second issue, CVE-2018-1000005, is described as an “HTTP/2 trailer out-of-bounds read”. The advisory says “reading an HTTP/2 trailer could mess up future trailers since the stored size was one byte less than required.”

“When accessed, the data is read out of bounds and causes either a crash or that the (too large) data gets passed to the libcurl callback. This might 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 second bug only exists in libcurl versions between 7.49.0 to 7.57.0. ®