DLL hijacking

from Wikipedia, the free encyclopedia

DLL hijacking (also known as binary planting or remote binary planting ) describes the loading of a DLL from a path not intended by the program developer. If the complete path to the DLL is not given, the Windows default is to first look in the folder in which the program itself is located. Many see this behavior as a security loophole that can be found in many programs under Microsoft Windows, as malicious code can be slipped into an application through a prepared DLL file, provided the programming allows it. Loading a DLL without specifying a complete path can also have a meaningful background. A so-called proxy DLL, a DLL that offers the same options as the DLL that is to be loaded, can be used to make an application more secure by checking the parameters of a function to ensure that they do not lead to a program crash. as it could be with an insecure native DLL. In addition, this system behavior allows a developer to load a DLL file with any name without worrying that a DLL with that name may be in the operating system folder and that this unknown DLL will be loaded instead of the DLL that the Developer is included.

functionality

In Windows, DLLs are explicitly loaded by programs during runtime using the WinAPI functions LoadLibraryand LoadLibraryEx; When loading programs and DLLs, statically linked DLLs are loaded implicitly by Windows' module loader. If a fully qualified path to the DLL is not specified, DLL hijacking is possible in both cases. The file to be loaded is then loaded using the search sequence specified by the Dynamic-Link Library Search Order , whereby the file is searched first in the program directory, then in the system directories, then in the working directory and finally in the directories specified by the environment variable PATH . A "local" DLL file is loaded and its code is executed if this DLL is in the directory of a data file to be opened and if the following conditions are met: The application (EXE file) or one of the DLLs it uses tries to use the extension ( DLL file) via the PATHvariable and changes from the working directory to the directory of the data file when it is opened.

This principle is comparable to the behavior of the "Run" dialog or the command prompt under Windows. If you enter the command cmd.exethere, the file is cmd.exefirst searched for in the selected path; if the system did not find what it was looking for, the file is searched for in the paths of the environment variable.

As it became known on September 8, 2010, in addition to the API function described, other functions are affected by this behavior, which is only officially documented on the English MSDN website. These are the functions CreateProcess*, ShellExecute*, WinExec, LoadModule, _spawn*p*and _exec*p*, the EXE to run files or processes start. The way it works is the same as mentioned above, although the individual search sequences differ.

On November 24, 2013, Stefan Kanthak published that when batch scripts were called via CreateProcess*resp. ShellExecute*a program in the working directory is being cmd.exeexecuted. Microsoft only closed this security hole, which has existed since at least Windows NT 4.0 , on April 8, 2014 with the security update MS14-019.

Schedule

Binary planting was first described in 2000. On August 18, 2010, this problem was discovered and published in iTunes by ACROS. The security gap was spread in the media. Microsoft issued a security advisory on this issue on August 23, 2010. Reloading DLLs from the working directory is part of the design of the operating system. Microsoft has made a recommendation for the safe loading of external libraries.

distribution

Initial estimates were based on around 200 affected programs. Within a few days, the number of security vulnerabilities found increased so much that the exploit database exploit-db.com no longer creates a separate entry for each exploit, but rather summarizes them in a list. An unofficial list is kept by Corelan's team. The programs affected include Firefox , Opera , Microsoft PowerPoint , µTorrent and VLC .

Countermeasures

A complete solution to the problem can only be provided by the application developers in the form of security updates . As a temporary solution, an update can be installed from the Microsoft Download Center, which makes a new registry entry in the operating system evaluable. With the entries to be inserted afterwards, the freedom to load DLLs from the working directory can be restricted or prevented in the entire system but also individually for individual applications, but this leads to problems with programs that correctly relate to the functional principle of LoadLibrary and other affected functions support. In addition, Microsoft recommends switching off the web client service and blocking TCP ports 139 and 445 in the firewall. This prevents access to network shares and WebDAV directories.

Individual evidence

  1. ↑ a b Microsoft: LoadLibrary Function (Windows). September 23, 2010. Retrieved September 29, 2010 .
  2. ↑ Microsoft: LoadLibraryEx Function (Windows). August 19, 2017. Retrieved August 19, 2017 .
  3. ^ Microsoft: Run-Time Dynamic Linking. August 19, 2017. Retrieved August 19, 2017 .
  4. ^ Microsoft: Load-Time Dynamic Linking. August 19, 2017. Retrieved August 19, 2017 .
  5. ^ Microsoft: Dynamic-Link Library Search Order. September 23, 2010. Retrieved August 29, 2010 .
  6. ↑ Christoph H. Hochstätter: Remote Binary Planting: The unpatchable gap in Windows. August 27, 2010, accessed September 18, 2010 .
  7. ↑ a b ACROS: ACROS Security Blog: Binary Planting Goes "EXE". September 8, 2010, accessed September 29, 2010 .
  8. ^ Stefan Kanthak: Exploit and Vulnerability Detector. Retrieved August 18, 2017 .
  9. ↑ Stefan Kanthak: Defense in depth - the Microsoft way (part 14): incomplete, misleading and dangerous documentation. November 13, 2013, accessed September 27, 2014 .
  10. ↑ Microsoft Security Bulletin MS14-019 - Critical. April 8, 2014, accessed September 27, 2014 .
  11. ↑ Georgi Guninski: Microsoft Windows DLL Search Path Weakness. September 18, 2000, accessed September 18, 2010 .
  12. ↑ ACROS: ACROS Security Problem Report # 2010-08-18-1. August 18, 2010, accessed September 18, 2010 .
  13. ↑ a b Unsecure library loading can allow remote code execution (2269637). August 23, 2010. Retrieved August 29, 2010 .
  14. ↑ a b Binary Planting: Windows vulnerability affects dozens of applications. August 24, 2010. Retrieved August 29, 2010 .
  15. ↑ Dynamic-Link Library Security. Retrieved August 29, 2010 .
  16. ↑ Researcher: Code-execution bug affects 200 Windows apps. August 20, 2010. Retrieved August 29, 2010 .
  17. ^ DLL Hijacking - Vulnerable Applications. August 25, 2010. Retrieved August 29, 2010 .
  18. ↑ a b DLL Hijacking (KB 2269637) - the unofficial list. (No longer available online.) Archived from the original on August 28, 2010 ; Retrieved August 29, 2010 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / www.corelan.be
  19. ↑ A new registry entry "CWDIllegalInDllSearch" for controlling the DLL search path algorithm is available. August 27, 2010. Retrieved August 29, 2010 .
  20. ↑ Binary Planting: Microsoft's workaround causes individual applications to fail. August 28, 2010. Retrieved August 29, 2010 .