Microsoft Issues Advisory and Tool To Address DLL Loading Issue

MSFTSecResponseAV_bigger.jpgIn response to new developments in the old vulnerability of insecure DLL loading Microsoft has released an advisory describing the problem, actions that may be taken by users, administrators and developers, actions they plan to take and a tool that administrators can use to mitigate vulnerable applications.

To recap, the basic vulnerability is an old one, reported at least 10 years ago for Windows. If an attacker can trick a user into opening a data file from the current directory, they may be able to cause the program to load a DLL (dynamic link library) of the attacker's creation from the same directory. Previous Windows versions of this attack, which also goes back many years on UNIX, required that the data file be on the local system. The innovation is that it can now be exploited on a network share or even a server on the Internet through WebDAV, firewalls permitting.

When the initial reports came out for Windows, Microsoft made changes to the default DLL loading order and provided other mechanisms for developers to prevent this from happening in their own programs. They moved the current directory way down the list of possibilities for loading a DLL, but they didn't eliminate it, fearing that it would cause too many incompatibilities with existing systems. But it's fair to say that where this problem exists, it exists as an error in the application, not in Windows.

The advisory gives a lot of advice. For developers, it recommends that they follow DLL security practices described on MSDN. For administrators, it lists workarounds of blocking TCP ports 139 and 445 at the firewall and disabling the WebClient service.

Microsoft also has issued an update to Windows which introduces a new registry key administrators or users can use to control the DLL search order, including the ability to prevent loading DLLs from shares or the current directory. The update and instructions for using the registry key may be found at MSKB article 2264107.

Finally, Microsoft says that they will be working with the security community and application vendors to determine where problems exist and help to remedy them.

blog comments powered by Disqus