curl / Docs / Security Problems / Negotiate not treated as connection-oriented

Negotiate not treated as connection-oriented

Project curl Security Advisory, April 22nd 2015 - Permalink

VULNERABILITY

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 connection 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.

We are not aware of any exploits of this flaw.

INFO

This flaw can also affect the curl command line tool if a similar operation series is made with that.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2015-3148 to this issue.

CWE-305: Authentication Bypass by Primary Weakness

AFFECTED VERSIONS

libcurl is used by many applications, but not always advertised as such!

THE WORK-AROUND

libcurl 7.42.0 closes Negotiate connections after they're done, effectively preventing wrongful re-use. We decided to do this blunt short-term fix to avoid this current problem and then continue to work on a better fix.

A patch for this problem is available at:

https://curl.se/CVE-2015-3148.patch

RECOMMENDATIONS

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade to curl and libcurl 7.42.0

B - Apply the patch and rebuild libcurl

C - Avoid using Negotiate with libcurl

TIME LINE

It was first reported to the curl project on March 31 2015. We contacted distros@openwall on April 18.

libcurl 7.42.0 was released on April 22nd 2015, coordinated with the publication of this advisory.

CREDITS

Thanks a lot!