-----BEGIN PGP SIGNED MESSAGE-----
-= Security Advisory =-
Advisory: libcurl URL Parsing Vulnerability
Release Date: 2005/12/07
Last Modified: 2005/12/07
Author: Stefan Esser [firstname.lastname@example.org]
Application: Curl <= 7.15.0
libcurl <= 7.15.0
Severity: When (lib)Curl tries to parse a certain kind of
malformed URLs this leads to a heap overflow
Vendor Status: Vendor has released an updated version
libcurl is a free and easy-to-use client-side URL transfer library,
supporting FTP, FTPS, TFTP, HTTP, HTTPS, GOPHER, TELNET, DICT, FILE
and LDAP. libcurl supports HTTPS certificates, HTTP POST, HTTP PUT,
FTP uploading, HTTP form based upload, proxies, cookies,
user+password authentication (Basic, Digest, NTLM, Negotiate,
Kerberos4), file transfer resume, http proxy tunneling and more!
During a quick scan of the URL parsing code within libcurl, it was
discovered, that certain malformed URLs trigger an off-by-one(two)
bufferoverflow. This may lead to unintended arbitrary code execution.
Because the attacker must be able to force curl to load such an URL,
which is not possible through a HTTP redirect, the impact is low.
However a local attacker might use this vulnerability to break out
of safe_mode/open_basedir restrictions when PHP is compiled with
When libcurl parses an URL it first allocates certain buffers for
the hostname part and the path. As long the URL is short a minimum
amount of 256 bytes is allocated for each of these buffers.
When the input URL exceeds the 256 byte limit, libcurl allocates
the two buffers in a size that is exactly the lenght of the input
URL. For typical URLs this is enough (although space for the 0
string termination byte is not allocated).
The URL is then parsed by a number of sscanf calls. Unfortunately
certain malformed URLs will result in sscanf copying the complete
input URL into either the host or the path buffer. Because the
initial allocation did not allocate the extra space for the 0 byte
this eventually results in an off by one situation.
While this overflow with one zero byte is already enough to
manipulate certain implementaions of malloc()/free(), it is possible
to cause a two byte overflow by starting a hostname with a ?
When libcurl finds a ? in the hostname it suspects a malformed URL
and inserts a path seperator / infront of it. This is performed
without any kind of size check.
This vulnerability is believed to be only triggerable through direct
requesting curl to load a malformed URL and NOT through a HTTP
redirect. Because this is usually not possible for remote attackers,
this vulnerability is rated low risk. This vulnerability might
however be used to break out of PHP's safe_mode/open_basedir when
it is compiled against libcurl. Additonally such an exploit might be
used to steal the local SSL certificate from apache memory.
Proof of Concept:
The Hardened-PHP Project is not going to release an exploit for
this vulnerability to the public.
29. November 2005 - Vulnerability was disclosed to the vendor
6. December 2005 - Vendor has released a bugfixed version
7. December 2005 - Public Disclosure
We strongly recommend to upgrade to the vendor supplied new
version of curl and libcurl.
pub 1024D/0A864AA1 2004-04-17 Hardened-PHP Signature Key
Key fingerprint = 066F A6D0 E57E 9936 9082 7E52 4439 14CC 0A86 4AA1
Copyright 2005 Stefan Esser / Hardened-PHP Project. All rights reserved.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----