Docs Overview
Project
Bug Bounty Bug Report Code of conduct Dependencies Donate FAQ Features Governance History Install Known Bugs Logo TODO website Info
Protocols
CA Extract HTTP cookies HTTP/3 MQTT SSL certs SSL libs compared URL syntax WebSocket
Releases
Changelog curl CVEs Release Table Version Numbering Vulnerabilities
Tool
Comparison Table curl man page HTTP Scripting mk-ca-bundle Tutorial When options were added
Who and Why
Companies Copyright Sponsors Thanks The name
curl / Docs / curl CVEs / Windows DLL hijacking
Related:
Audits
Bug Bounty
Changelog
curl CVEs
JSON metadata
Vulnerability Disclosure
Vulnerabilities Table

CVE-2016-4802

Windows DLL hijacking

Project curl Security Advisory, May 30th 2016 - Permalink

VULNERABILITY

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 the 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.

INFO

This flaw also affects the curl command line tool.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2016-4802 to this issue.

CWE-94: Improper Control of Generation of Code ('Code Injection')

Severity: High

AFFECTED VERSIONS

This flaw is relevant for all versions of curl and libcurl on Windows that support SSPI or Telnet.

libcurl is used by many applications, but not always advertised as such!

SOLUTION

In version 7.49.1, libcurl loads DLLs from the Windows system directory, either via LoadLibraryEx() and LOAD_LIBRARY_SEARCH_SYSTEM32, where supported, or by explicitly finding the system directory.

RECOMMENDATIONS

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade curl and libcurl to version 7.49.1

B - Apply the patch to your version and rebuild

C - Build your libcurl without SSPI and Telnet support enabled

Additionally in any case you should secure write permissions to your application directory and if you are using the curl tool exercise judicious use of --remote-header-name (also usable as -J). The -J option when combined with -O lets the server choose the filename. A rogue server could send you the name of a DLL or other file that could be used in a planting attack.

TIMELINE

It was first reported to the curl project on May 7 2016. We contacted MITRE on May 13.

libcurl 7.49.1 was released on May 30 2016, coordinated with the publication of this advisory.

CREDITS

Thanks a lot!