SMB access smuggling via FILE URL on Windows
Project curl Security Advisory, January 8th 2020 - Permalink
As of March 2020, the curl security team has reconsidered this issue and we no longer consider this a curl security flaw. This "SMB access" (that also can be done using other network protocols) is a Windows feature that cannot be avoided or switched off by an application or library and we have stopped trying. All and any such network accesses via file accesses are no longer considered a curl bug, but a Windows feature. curl and libcurl on Windows that uses
FILE:// URLs might generate such probes.
For the sake of history, we keep the advisory as it was originally stated below.
libcurl can be told to load a file from a
FILE:// URL. It will then load the file from the path specified in the URL from the local file system.
If you craft the given path so that it starts with two slashes (or backslashes) followed by a host name, Windows systems will automatically treat that as a request to access the host name using SMB instead of reading a local file with that name. This is not expected nor documented libcurl behavior.
Applications allowing users to provide URLs or parts of URLs could be vulnerable to this flaw. Both the curl tool and library.
Example URL exploiting this:
This bug only exists when libcurl runs on a Microsoft Windows operating system.
This bug exists in the first code import we have, from 1999.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2019-15601 to this issue.
CWE-20: Improper Input Validation
- Affected versions: curl 4.0 to and including 7.67.0
- Not affected versions: libcurl >= 7.68.0
- Introduced-in: https://github.com/curl/curl/commit/ae1912cb0d494b48d
libcurl is used by many applications, but not always advertised as such.
We suggest you take one of the following actions immediately, in order of preference:
A - Upgrade curl to version 7.68.0
B - Apply the patch to your version and rebuild
C - do not use
The issue was reported to the curl project on October 31, 2019. The initial fix was done, verified and communicated with the reporter on November 7, 2019.
This advisory was posted on January 8th 2020.
- Reported-by: Fernando Muñoz
- Patched-by: Daniel Stenberg
Thanks a lot!