There are many benefits to using shared libraries, including modularity, code reuse, reduced disk space, efficient memory usage and faster load time. A module is only loaded when its functionality or resources are requested. Importantly, modularity allows changes to be made to a DLL shared by several applications without having to make changes to each application individually. For example, the comdlg32 DLL handles opening a dialog box in Windows. Any application running on Windows can tap into that DLL to use that functionality, enabling Microsoft to ensure a consistent user interface with any changes it makes to comdlg32.dll by cascading through to every other application without forcing rebuilds or reinstallations of third-party programs.
When Microsoft first introduced DLLs, it led to problems of compatibility and dependency, which came to be known as "DLL hell." This situation was dramatically improved in Windows 95, in which every process runs in its own address space and Windows 2000, which introduced Windows File Protection to prevent applications from overwriting system DLLs. However, like any file containing executable code, hackers can manipulate DLLs to run malicious code.
In fact, the way DLLs are loaded has created a particular attack vector called "DLL preloading attacks," which hit the news this past summer. If an application dynamically loads a DLL without specifying a fully qualified path name, Windows attempts to locate the DLL by searching a well-defined set of directories. If an attacker can copy a malicious version of the DLL into one of these directories, the application will load and execute the malicious DLL. This illustrates how hackers will look to abuse any aspect of a system's design to create a new attack vector.
Note: Microsoft has published an update about this vulnerability on its Microsoft Security Response Center website and you can download a tool that modifies the DLL search sequence.
This was first published in September 2010