Mitigating Insecure Library Loading Vulnerability

Insecure library loading or dll hijacking vulnerability occurs when libraries are loaded from a location not intended to load from due to how Windows search order works when searching for the library. This really comes down to developers not specifying the fully qualified path name of the library or not initially calling SetDllDirectory() with a blank path in its code. So for example when opening a document the application searches for the required dll and if located in the current working directory of the document the dll will get loaded from this location.

There has been a huge number of advisories published so far containing this type of vulnerability in applications and only a handful of them have been patched. Check out Secunia’s verified list to see if you are affected. Microsoft has also released an update giving us some control to what search paths not to query. Once the patch is installed you will need to add the dword value name “CWDIllegalInDllSearch” in the registry key location

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]

The value data can be 1, 2 or ffffffff. If the value name CWDIllegalInDllSearch does not exist or the value data is 0 then the machine will still be vulnerable to attack. Please be aware that the value ffffffff could break certain applications.

Depending on the value you choose you still might be vunerable. After doing some tests I’ve produced this table below hopefully making it clearer as I found the Microsoft advisory a bit confusing.

Location                               Example                                   CWDIllegalInDllSearch    Safe  
Local machine C:\MyDocuments 2 no
Mapped drive H: 2 yes
UNC share \\PC1\share 2 yes
Removable disk Usb drive G: 2 no
WebDav share http://site/virtualfolder 2 yes
Local machine C:\MyDocuments 1 no
Mapped drive H: 1 no
UNC share \\PC1\share 1 no
Removable disk Usb drive G: 1 no
WebDav share http://site/virtualfolder 1 yes
Local machine C:\MyDocuments ffffffff yes
Mapped drive H: ffffffff yes
UNC share \\PC1\share ffffffff yes
Removable disk Usb drive G: ffffffff yes
WebDav share http://site/virtualfolder ffffffff yes

WebDav share has to be connected as an unc share i.e. \\\webdavshare or mapped to a drive letter. Exploitation via WebDav shares can be mitigated by disabling the Webclient service. Finally, when testing WebDav connections you might end up getting this error “The workstation driver is not installed”. If so you’ll need to stop the WebDav Client Redirector driver (C:\>net stop mrxdav) and then start the WebClient service again.


Leave a Reply

Your email address will not be published. Required fields are marked *