|
|
|
|
| |
"curl is a command line tool for transferring files with URL syntax, supporting FTP, FTPS, TFTP, HTTP, HTTPS, GOPHER, TELNET, DICT, FILE and LDAP."
By badly allocation the size of the buffers to the exact length of user provided input, attackers can cause a buffer overflow in Curl and cause it to execute arbitrary code. |
| |
Credit:
The information has been provided by Stefan Esser.
The original article can be found at: http://www.hardened-php.net/advisory_242005.109.html
|
| |
Vulnerable Systems:
* curl version 7.15.0 and prior
* libcurl version 7.15.0 and prior
Immune Systems:
* curl version 7.15.1
* libcurl version 7.15.1
When libcurl parses a URL, it first allocates certain buffers for the hostname part and the path. As long as 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 length 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 implementations of malloc()/free(), it is possible to cause a two byte overflow by starting a hostname with a question mark char (?). When libcurl finds the question mark char in the hostname it suspects a malformed URL and inserts a path separator / in front of it. This is performed without any kind of size check.
This vulnerability is believed to be only trigger through direct request of 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 any program that compiled against libcurl.
Disclosure Timeline:
29. November 2005 - Vulnerability was disclosed to the vendor
6. December 2005 - Vendor has released a bugfixed version
7. December 2005 - Public Disclosure
|
|
|
|
|
