Front PageSecurity
|
| |
|
|
|
Security
|
cURL  Docs Security
curl SecurityWe take security seriously and develop curl and libcurl to be secure and safe. If you find or simply suspect a security problem in curl or libcurl, mail us at curl-security at haxx.se (closed list of receivers, mails are not disclosed) and tell. We appreciate getting notified in advance before you go public with security advisories for the sake of our users. See also the Vulnerabilties Table to see what versions that are vulnerable to what flaws. libcurl embedded zero in cert name
SSL and TLS Server certificates contain one or more fields with server name or otherwise matching patterns. These strings are stored as content and length within the certificate, and thus there is no particular terminating character. curl's OpenSSL interfacing code did faulty assumptions about those names and patterns being zero terminated, allowing itself to be fooled in case a certificate would get a zero byte embedded into one of the name fields. To illustrate, a name that would show this vulnerability could look like:
"example.com\0.haxx.se"
This cert is thus made for "haxx.se" but curl would erroneously verify it with no complaints for "example.com". According to a recently published presentation, this kind of zero embedding has been proven to be possible with at least one CA. libcurl Arbitrary File Access
When told to follow a "redirect" automatically, libcurl does not question the new target URL but will follow to any new URL that it understands. As libcurl supports FILE:// URLs, a rogue server can thus "trick" a libcurl-using application to read a local file instead of the remote one. This is a problem, for example, when the application is running on a server and is written to upload or to otherwise provide the transfered data to a user, to another server or to another application etc, as it can be used to expose local files it was not meant to. The problem can also be exploited for uploading, if the rogue server redirects the client to a local file and thus it would (over)write a local file instead of sending it to the server. libcurl compiled to support SCP can get tricked to get a file using embedded semicolons, which can lead to execution of commands on the given server. "Location: scp://name:passwd@host/a'``;date >/tmp/test``;'". Files on servers other than the one running libcurl are also accessible when credentials for those servers are stored in the .netrc file of the user running libcurl. This is most common for FTP servers, but can occur with any protocol supported by libcurl. Files on remote SSH servers are also accessible when the user has an unencrypted SSH key. libcurl GnuTLS insufficient cert verification
libcurl (when built to use GnuTLS) fails to verify that a peer's certificate hasn't already expired or hasn't yet become valid. This allows malicious servers to present certificates to libcurl that won't be rejected properly. Notably, the cacert and common name checks are still in place which reduces the risk for random servers to take advantage of this flaw. libcurl TFTP Packet Buffer Overflow
libcurl uses the given file part of a TFTP URL in a manner that allows a malicious user to overflow a heap-based memory buffer due to the lack of boundary check. libcurl URL Buffer Overflow
libcurl's URL parser function can overflow a malloced buffer in two ways, if given a too long URL. libcurl NTLM Buffer Overflow
libcurl's NTLM function can overflow a stack-based buffer if given a too long user name or domain name. This would happen if you enable NTLM authentication and either:
There is no known exploit/malicious server at the time of this writing. The notification mail to us about this flaw was also sent to a public wget mailing list and thus became public immediately. Kerberos Authentication Buffer Overflow
Due to bad usage of the base64 decode function to a stack-based buffer without checking the data length, it was possible for a malicious FTP server to overflow the client during krb4 negotiation. I don't know of any single user that uses krb4-ftp and I'm not even sure it still works 100%. The announcement was done without contacting us. NTLM Authentication Buffer Overflow
Due to bad usage of the base64 decode function to a stack-based buffer without checking the data length, it was possible for a malicious HTTP server to overflow the client during NTLM negotiation. The announcement was done without contacting us. Proxy Authentication Header Information Leakage
When curl connected to a site via an HTTP proxy with the CONNECT request, the user and password used for the proxy connection was also sent off to the remote server. FTP Server Response Buffer Overflow
When storing an FTP server's error message on failure, there was no check for input length and thus a malicious FTP server could overflow curl's stack based buffer. securityfocus lists two exploits |
Page updated December 8, 2009.
web site info