curl does not sanitize colons in a remote file name that is used as the local file name. This may lead to a vulnerability on systems where the colon is a special path character. Currently Windows is the only OS where this vulnerability applies.
curl offers command line options --remote-name (also usable as -O) and --remote-header-name (also usable as -J). When both of those options are used together (-OJ) and the server provides a remote file name for the content, curl will write its output to that server-provided file name, as long as that file does not already exist. If it does exist curl will fail to write. If both options are used together (-OJ) but the server does not provide a remote file name, or if -O is used without -J, curl will write output to a file name based solely on the remote file name in the URL string provided by the user, regardless of whether or not that file already exists.
In either case curl does not sanitize colons in the file name. As a result in Windows it is possible and unintended behavior for curl to write to a file in the working directory of a drive that is not the current drive (ie outside the current working directory), and also possible to write to a file's alternate data stream.
For example if curl -OJ and the server sends filename=f:foo curl will incorrectly write foo to the working directory for drive F even if drive F isn't the current drive. For a more detailed explanation see the 'MORE BACKGROUND AND EXAMPLE' section towards the end of this advisory. Though no known exploit is available for this issue, writing one would be undemanding and could be serious depending on the name of the file and where it ends up being written.
CVSS Scores & Vulnerability TypesCVSS Score 5.0
Confidentiality Impact None (There is no impact to the confidentiality of the system.)
Integrity Impact Partial (Modification of some system files or information is possible, but the attacker does not have control over what can be modified, or the scope of what the attacker can affect is limited.)
Availability Impact None (There is no impact to the availability of the system.)
Access Complexity Low (Specialized access conditions or extenuating circumstances do not exist. Very little knowledge or skill is required to exploit. )
Authentication Not required (Authentication is not required to exploit the vulnerability.)
Gained Access NoneINFOThis flaw only affects the curl command line tool as this is a feature not present or provided by libcurl. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2016-0754 to this issue. CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
AFFECTED VERSIONSIn the case of using a remote file name provided by the user (-O without -J), the feature has existed since inception.
>> Affected versions (-O): curl <= 7.46.0
>> Not affected versions (-O): curl >= 7.47.0
In the case of using a remote file name provided by the server (-OJ), the feature was added in 7.20.0 and didn't exist before then.
>> Affected versions (-OJ): curl 7.20.0 to and including 7.46.0
>> Not affected versions (-OJ): curl < 7.20.0 and curl >= 7.47.0
curl built for Cygwin is partially affected (-O): curl <= 7.47.0. Please refer to the CYGWIN addendum at the end of this advisory. (Added 2016-02-07)
THE SOLUTIONStarting in curl 7.47.0 the curl tool in Windows will replace all colons in a remote file name with underscores. For example if f:foo::$DATA is the remote file name it will be sanitized as f_foo__$DATA .
A patch is available at:
https://curl.haxx.se/CVE-2016-0754_v3_curl-7.24.0_to_7.39.0.patchhttps://curl.haxx.se/CVE-2016-0754_v3_curl-7.40.0_to_7.46.0.patchhttps://curl.haxx.se/CVE-2016-0754_v3_curl-7.47.0.patchThe patch also includes two fixes not present in 7.47.1 for accessing paths using the literal path prefix \\?\ and accessing reserved dos device names without using the device prefix \\.\. If you have applied an older version of the patch revert it and then apply v3. There is no patch for curl < 7.24.0, see RECOMMENDATIONS for alternatives.
Exercise judicious use of the -J option. The -J option when combined with -O lets the server choose the file name. Do you trust the server you are using the -J option on? Is your connection to the server vulnerable to a man-in-the-middle attack? Have you enabled location redirects and the server may send you somewhere untrustworthy? In any of these cases, even with this vulnerability fixed know that if you use the -J option it will still be possible for a rogue server to send you the name of a DLL or other file that could possibly be loaded automatically by Windows or some third party software.
RECOMMENDATIONS
We suggest you take one of the following actions immediately, in order of preference:
A - Upgrade curl and libcurl to version 7.47.1.
B - Apply the patch to your version and rebuild.
C - If you cannot do (A) or (B) it is suggested you do not use -J on Windows. If you choose to continue to use -O without -J it is your responsibility to check that the URL you pass does not have a remote file name that could be exploited.
Regardless of which action you take, exercise judicious use of the -J option as described in THE SOLUTION.
