A vulnerability was recently discovered in Microsoft Windows operating systems that exploits the default dll loading behavior.
A Microsoft Security Advisory explains that the “issue is caused by specific insecure programming practices that allow so-called binary planting or DLL preloading attacks”.
In simple terms: Applications that do not use qualified paths for external dynamic link libraries use Windows default settings to find those dlls on the system, and one of the first locations to be searched is the program directory, which can be a local or remote directory.
The exploit dlls simply have to be placed in those directories to be executed by applications. Affected are many popular programs, including Firefox, VLC, Opera, Photoshop, uTorrent or PowerPoint.
Microsoft published additional information about the DLL preloading remote attack vector in a blog post on the Security Research and Defense blog.
Among the information is a workaround that requires the creation of Registry keys to change the library loading behavior either on a system wide level, or for specific applications.
You can open the Registry Editor in the following way:
- Tap on the Windows-key, type regedit and hit enter.
- Confirm the UAC prompt.
- Navigate to the following path: HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session Manager/CWDIllegalInDllSearch
- Or this path, if you want to configure application-specific behavior: HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/Image File Execution Options/binaryname.exe/CWDIllegalInDllSearch
To create the CWDIllegalInDllSearch key, right-click on Session Manager and select New > Dword (32-bit Value) if you want to improve the protection on a system-wide level, or right-click on “Image File Execution Options, select New > Key, name it like the file name of the application you want to harden against the attack, and then right-click on the newly created key and select New > Dword (32-bit Value) as well to create CWDIllegalInDllSearch.
Both keys support the following values, which have different effects depending on the location of the application:
Scenario 1: The application is started from a local folder, such as C:Program Files
0xffffffff Removes the current working directory from the default DLL search order.
0 Uses the default DLL search path. This is the Windows default, and the least secure setting.
1 Blocks a DLL load from the current working directory if the current working directory is set to a WebDAV folder.
2 Blocks a DLL load from the current working directory if the current working directory is set to a remote folder.Scenario 2: The application is started from a remote folder, such as \remoteshare
0xffffffff Removes the current working directory from the default DLL search order.
0 Uses the default DLL search path. This is the Windows default, and the least secure setting.
1 Blocks a DLL load from the current working directory if the current working directory is set to a WebDAV folder.
2 Allows DLL load from the current working directory if the current working directory is set to a remote folder. DLL’s that are loaded from a WebDAV share are blocked if the current working directory is set to a WebDAV share.Scenario 3: The application is started from a WebDAV folder, such as http://remote/share
0xffffffff Removes the current working directory from the default DLL search order.
0 Uses the default DLL search path. This is the Windows default, and the least secure setting.
The suggested value is 0xffffffff as it protects the system against these types of dll side-loading attacks. Please note that you may run into compatibility issues when you are making the change on a system-wide level.
You can use the application-specific setting in this case to change the default value.