Critical vulnerability in cURL library could affect large number of applications
Libcurl 7.29.0 addresses a critical remote code execution vulnerability
By Lucian Constantin | Published: 09:47, 12 February 2013
A critical buffer overflow vulnerability patched this week in the widely used open-source cURL library (libcurl) has the potential to expose a large number of applications and systems to remote code execution attacks.
CURL is a cross-platform command line tool and library for transferring data using URL (uniform resource locator) syntax. It supports a wide range of protocols including HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, DICT, FILE, FTP, FTPS, Gopher, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, Telnet and TFTP.
The vulnerability can be exploited when a program that uses libcurl or the cURL command line tool communicates with a malicious server over the POP3, SMTP or IMAP protocols, the cURL developers said Wednesday in a security advisory. The flaw is located in the libcurl function that handles SASL DIGEST-MD5 authentication and affects versions 7.26.0 to 7.28.1 of the library, they said.
Libcurl 7.29.0 was released Wednesday to address the flaw. However, the issue can also be mitigated by using the CURLOPT_PROTOCOLS option to disable support for the vulnerable protocols at run-time.
Vulnerability research and management firm Secunia rated the flaw as highly critical. "Successful exploitation may allow execution of arbitrary code but requires tricking a user into connecting to a malicious server," the company said Thursday in a security advisory.
Even though a potential exploit involves POP3, IMAP or SMTP authentication, HTTP URLs can also be used as an initial attack vector because cURL supports redirection, said Volema, the vulnerability research outfit that discovered the vulnerability, in a blog post Wednesday.
If a program that uses libcurl is instructed to open an HTTP URL to a malicious server, the server can respond with status "302 Found" and redirect the library to another location, which can be pop3://x:email@example.com/, Volema said. The library will then attempt authentication and the server can deliver the exploit.
There's a run-time option called CURLOPT_FOLLOWLOCATION that can be used to prevent libcurl from following "Location" headers sent in HTTP responses. If this feature is needed, another option called CURLOPT_REDIR_PROTOCOLS can be used to limit what protocols are supported for redirect attempts.
"I don't expect that many applications use these options to limit exposure - at least not before this discovery," Carsten Eiram, chief research officer at security firm Risk Based Security, said Friday via email.
CURL is highly portable and works on Windows, Mac OS X, Linux, Solaris, BSD variants, other UNIX-derived OSes including those for embedded systems, as well as mobile OSes like iOS, Android, BlackBerry Tablet OS and BlackBerry 10 OS. This makes it very popular among application developers who would rather use an already robust library for data transfer than code their own solution from scratch.
The library is used by a wide range of desktop, Web and mobile applications. According to the cURL developers it's even used in Internet-connected TV sets and Bluray players, in embedded systems and in games. An incomplete list of applications that use libcurl is available on the project's website.
Some applications bundle a copy of the library with their installers while others use the version of the library installed on the operating system. Some Linux distributions come with libcurl installed by default, while others provide it as an optional package.
Because of the many ways and places where libcurl is used, a lot of systems and applications are likely to remain vulnerable to this vulnerability for some time to come, despite a patch being available.
This will especially be the case for those applications that use it statically, meaning that the applications include a copy of the library, Eiram said.
"This is one of the problems in general with software that often includes a lot of third-party components and libraries," Eiram said. "How do these software vendors get informed about vulnerabilities in any components that they bundle, and how quick are they at evaluating if their software is vulnerable and update it?"
"We regularly see products affected by vulnerabilities in their bundled components, which were fixed upstream a long time ago," he said. "An example is the latest UPnP research by Rapid7. Some of the described vulnerabilities were fixed many years ago, yet device vendors are still using old, vulnerable versions of the components."
Eiram believes that if a reliable exploit is released, there will definitely be attacks that will target this vulnerability. "We will at least see random websites trying to exploit this if targets happen -- or are tricked -- to visit it with a vulnerable application," he said.