libcurl keeps a pool of its last few connections around after use to fascilitate easy, conventient and completely transparent connection re-use for applications. When doing HTTP requests NTLM authenticated, the entire connnection becomes authenticated and not just the specific HTTP request which is otherwise how HTTP works. This makes NTLM special and a subject for special treatment in the code. With NTLM, once the connection is authenticated, no further authentication is necessary until the connection gets closed. libcurl's connection re-use logic will select an existing connection for re-use when asked to do a request, and when asked to use NTLM libcurl have to pick a connection with matching credentials only. If a connection was first setup and used for an NTLM HTTP request with a specific set of credentials, that same connection could later wrongly get re-used in a subsequent HTTP request that was made to the same host - but without having any credentials set! Since an NTLM connection was already authenticated due to how NTLM works, the subsequent request could then get sent over the wrong connection appearing as the initial user. This problem is very similar to the previous problem known as CVE-2014-0015. The main difference this time is that the subsequent request that wrongly re-use a connection doesn't ask for NTLM authentication.
There is a private function in libcurl called fix_hostname() that removes a trailing dot from the host name if there is one. The function is called after the host name has been extracted from the URL libcurl has been told to act on. If a URL is given with a zero-length host name, like in "<A HREF="http://:80">http://:80</A>" or just ":80", fix_hostname() will index the host name pointer with a -1 offset (as it blindly assumes a non-zero length) and both read and assign that address. At best, this gets unnoticed but can also lead to a crash or worse. We have not researched further what kind of malicious actions that potentially this could be used for.
libcurl supports HTTP "cookies" as documented in RFC 6265. Together with each individual cookie there are several different properties, but for this vulnerability we focus on the associated "path" element. It tells information about for which path on a given host the cookies is valid. The internal libcurl function called sanitize_cookie_path() that cleans up the path element as given to it from a remote site or when read from a file, did not properly validate the input. If given a path that consisted of a single double-quote, libcurl would index a newly allocated memory area with index -1 and assign a zero to it, thus destroying heap memory it wasn't supposed to. At best, this gets unnoticed but can also lead to a crash or worse. We have not researched further what kind of malicious actions that potentially this could be used for. Applications have to explicitly enable cookie parsing in libcurl for this problem to trigger, and if not enabled libcurl will not hit this problem.
libcurl keeps a pool of its last few connections around after use to fascilitate easy, conventient and completely transparent connection re-use for applications. When doing HTTP requests Negotiate authenticated, the entire connnection may become authenticated and not just the specific HTTP request which is otherwise how HTTP works, as Negotiate can basically use NTLM under the hood. curl was not adhering to this fact but would assume that such requests would also be authenticated per request. The net effect is that libcurl may end up re-using an authenticated Negotiate connection and sending subsequent requests on it using new credentials, while the connection remains authenticated with a previous initial credentials setup.