cURL goes wrong

The open source file transfer library libcURL contains a critical vulnerability that can make attempts to retrieve a web page actually retrieve and execute arbitrary code. The interesting thing about the gap is that the hole is in the code that plugs in to communicate with mail servers; the trick is that it can be exploited when calling a normal HTTP URL. All this requires is that the web server that is being retrieved from redirects the library to a mail server by responding

HTTP/1.0 302 Found
Location: pop3://x:[email protected]/.

cURL supports the ability to follow redirections when retrieving in HTTP and HTTPS and also supports POP3 mail protocols. If you want to see an example of this, try curl -v pop3://test:[email protected]. If cURL contacts a POP3 server, the latest versions send the CAPA command the establish the capabilities of the POP3 server. To exploit the vulnerability, the server needs to announce that it supports SASL DIGEST-MD5. This ensures that cURL sends a request to the server of AUTH DIGEST-MD5 in the Curl_sasl_create_digest_md5_message() function and then takes the data returned from the server without doing appropriate length checks. That data is then appended to a fixed size buffer on the stack resulting in a buffer overflow. An exploit is already in circulation.

According to the advisory, the cURL developers can exploit this vulnerability via POP3, IMAP and SMTP. The hole is controversial not because of the command line tools but because of the many programs and scripts that make use of the libcURL library. The problem affects versions of libcURL from version 7.26.0 to the current 7.28.1; earlier versions are unaffected. The simplest fix is to download and build cURL and libcURL 7.29.0 from the cURL download page. Users who cannot upgrade can protect themselves by disabling the three protocols by setting the CURLOPT_PROTOCOLS and CURLOPT_REDIR_PROTOCOLS options to only use the protocols they need. A patch is also available for the vulnerable versions.

(djwm)