Editing DLL hell (section)

==Causes==
DLL incompatibility has been caused by:
* Memory constraints, combined with lack of separation of process memory space in 16-bit versions of Windows;
* Lack of enforced standard versioning, naming, and file-system location [[Model (abstract)|schemata]] for DLLs;
* Lack of an enforced standard method for software installation and removing ([[package management]]);
* Lack of centralized authoritative support for DLL [[application binary interface]] management and safeguards, allowing incompatible DLLs with the same file name and internal version numbers to be released;
* Oversimplified management tools, preventing the identification of changed or problematic DLLs by users and administrators;
* Developers breaking backward compatibility of functions in shared modules;
* Microsoft releasing out-of-band updates to operating-system runtime components;
* Inability of earlier versions of Windows to run side-by-side conflicting versions of the same library;
* Reliance on the current directory or <code>%PATH%</code> environment variable, both of which vary over time and from system to system, to find dependent DLLs (instead of loading them from an explicitly configured directory);
* Developers re-using the ClassIDs from sample applications for the COM interfaces of their applications, rather than generating their own new [[Globally unique identifier|GUIDs]].

DLL hell was a very common phenomenon on pre-Windows NT versions of Microsoft operating systems, the primary cause being that the 16-bit operating systems did not restrict processes to their own memory space, thereby not allowing them to load their own version of a shared module that they were compatible with. Application installers were expected to be good citizens and verify DLL version information before overwriting the existing system DLLs. Standard tools to simplify application deployment (which always involves shipping the dependent operating-system DLLs) were provided by Microsoft and other 3rd-party tools vendors. Microsoft even required application vendors to use a standard installer and have their installation program certified to work correctly, before being granted use of the Microsoft logo. The good-citizen installer approach did not mitigate the problem, as the rise in popularity of the Internet provided more opportunities to obtain non-conforming applications.

===Use by malware===
Windows searches several locations for ambiguous DLLs, i.e. ones not fully qualified. [[Malware]]s can exploit this behavior in several ways collectively known as ''DLL search order hijacking''. One method is ''DLL preloading'' or a ''binary planting attack''. It places DLL files with the same name in a location that is searched earlier, such as the current working directory. When the vulnerable program tries to load the DLL, the malicious version is executed, possibly at high privilege levels if the program runs at that level.<ref name="mitre-attack">{{Cite web |last=Holston |first=Ami |last2=Liang |first2=Marina |last3=Kanthak |first3=Stefan |last4=Smith |first4=Travis |last5=Alexander |first5=Will |date=30 September 2024 |title=Hijack Execution Flow: DLL Search Order Hijacking, Sub-technique T1574.001 - Enterprise |url=https://attack.mitre.org/versions/v16/techniques/T1574/001/ |access-date=2024-12-07 |website=ATT&CK |series=Version 1.3 |publisher=MITRE |id=T1574.001}}</ref>

Another method is ''relative path DLL hijacking'', which moves the vulnerable program to a location together with the malicious DLL. The DLL is loaded because the application's directory is searched early. According to [[CrowdStrike]], this method is the most common.<ref name="crowdsource">{{Cite web |author=Falcon OverWatch Team |date=December 30, 2022 |title=4 Ways Adversaries Hijack DLLs |url=https://www.crowdstrike.com/en-us/blog/4-ways-adversaries-hijack-dlls/ |access-date=2024-12-07 |website=CrowdStrike |language=en-US}}</ref> ''DLL sideloading'' delivers both the legitimate program and malicious library. It may avoid detection because the execution seems as running a reputable program.<ref name="checkpoint-research">{{Cite web |date=2024-09-25 |title=10 Years of DLL Hijacking, and What We Can Do to Prevent 10 More |url=https://research.checkpoint.com/2024/10-years-of-dll-hijacking-and-what-we-can-do-to-prevent-10-more/ |access-date=2024-12-07 |website=Check Point Research |language=en-US}}</ref>

Other methods include ''phantom DLL hijacking'', where a malicious DLL file is created against references to a non-existent library, and changing registry values to abuse ''DLL redirection'', which changes the DLL search order.<ref name="mitre-attack" />

DLL hijacking was used by state-sponsored groups including [[Lazarus Group]] and [[Tropic Trooper]].<ref name="checkpoint-research" />