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
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.
|Removable disk||Usb drive G:||2||no|
|Removable disk||Usb drive G:||1||no|
|Removable disk||Usb drive G:||ffffffff||yes|
WebDav share has to be connected as an unc share i.e. \\192.168.1.6\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.