CVE-2016-4802

Multiple untrusted search path vulnerabilities in cURL and libcurl before 7.49.1, when built with SSPI or telnet is enabled, allow local users to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse (1) security.dll, (2) secur32.dll, or (3) ws2_32.dll in the application or current working directory.

Multiple untrusted search path vulnerabilities in cURL and libcurl before 7.49.1, when built with SSPI or telnet is enabled, allow local users to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse (1) security.dll, (2) secur32.dll, or (3) ws2_32.dll in the application or current working directory.

Multiple untrusted search path vulnerabilities in cURL and libcurl before 7.49.1, when built with SSPI or telnet is enabled, allow local users to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse (1) security.dll, (2) secur32.dll, or (3) ws2_32.dll in the application or current working directory.

Multiple untrusted search path vulnerabilities in cURL and libcurl before 7.49.1, when built with SSPI or telnet is enabled, allow local users to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse (1) security.dll, (2) secur32.dll, or (3) ws2_32.dll in the application or current working directory.

Multiple untrusted search path vulnerabilities in cURL and libcurl before 7.49.1, when built with SSPI or telnet is enabled, allow local users to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse (1) security.dll, (2) secur32.dll, or (3) ws2_32.dll in the application or current working directory.

libcurl would load Windows system DLLs in a manner that may make it vulnerable to a DLL hijacking (aka binary planting) attack in certain configurations.

libcurl has a unified code base that builds and runs on a multitude of different versions of Windows. To make that possible, when libcurl is built with SSPI or telnet is used, it dynamically loads some of the necessary system DLLs at runtime by calling LoadLibrary(). No path is specified for these DLLs.

To find a DLL when no path is specified LoadLibrary() follows DLL search order to load it. If it is a "known DLL" no searching is done, the system copy is used. If it is not a "known DLL": The application directory is searched first. The current directory is searched next, if DLL safe search mode is not enabled. The system directory is searched next.

The 3 system DLLs libcurl loads dynamically are security.dll, secur32.dll and ws2_32.dll (a "known DLL" when installed). These DLLs may not be present on some versions of Windows, which is why they are loaded dynamically. Depending on a number of factors outlined in the DLL search order document it may be possible for an attacker to plant a DLL of the same name in the user's current directory, application directory or other directory in the DLL search order, thereby possibly causing it to be loaded first.

Recent versions of Windows include all 3 of those dynamically loaded system DLLs and also enable safe DLL search mode by default. Therefore in such a case ws2_32.dll could not be planted, and security.dll or secur32.dll could only be planted in the application directory.

To address this issue we have changed libcurl so that any system DLL it dynamically loads in Windows is done in the most secure way available.

Note if an attacker has the ability to write new files to your application directory they can likely still plant DLLs to be loaded in any case, load-time or runtime. This is by design in Windows DLL loading (refer to the DLL search order doc). For example it may be possible to override DLL search paths by planting an app.exe.local file or possibly a fake manifest. There is nothing we can do to prevent against this. We advise you to guard write permissions on your application directory.

Also note it is may still be possible for planting attacks to be done against load-time DLLs used by libcurl and the curl tool. This is because Windows loads those DLLs and their dependencies without specifying a path. There is nothing we can do to fix this, it is endemic in the design of Windows. We advise you to guard write permissions on your application directory.