cookie parser out of boundary memory access
Project curl Security Advisory, April 22nd 2015 - Permalink
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 cookie 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.
We are not aware of any exploits of this flaw.
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-3145 to this issue.
CWE-124: Buffer Underwrite ('Buffer Underflow')
- Affected versions: from libcurl 7.31.0 to and including 7.41.0
- Not affected versions: libcurl >= 7.42.0
libcurl is used by many applications, but not always advertised as such!
libcurl 7.42.0 better verifies the input string.
A patch for this problem is available at:
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 cookies with libcurl
It was first reported to the curl project on April 16 2015. We contacted distros@openwall on April 17th.
libcurl 7.42.0 was released on April 22nd 2015, coordinated with the publication of this advisory.
Reported by Hanno Böck
Thanks a lot!