All posts for the month October, 2010

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.


There are a number of possibilities as to why folders cannot be deleted but this one I came across recently got my attention. While decompressing a zip file it created its extracted folder but when I came to remove the folder it came up with the error “Cannot delete file: Cannot read from the source file or disk”. After investigating I realised that it had a trailing space at the end of the folder. Now I knew what was causing the removal to fail but how to get rid of it?

Well there are a few ways on how to remove folders with trailing spaces:

1. Using the “\\?\” syntax
2. Using 8.3 short filename format (if folder is more than 8 characters)

Below is an example code which creates a folder called “testfolder” in C:\TEMP with a trailing space. Note that after the space \\ is required for it to create the space after the folder. Once compiled and run it will create the testfolder, pause for 5 seconds and then remove it. The trailing space can be more than just one space character.

#include <stdio.h>
#include <windows.h>

int main()
    CreateDirectory(“C:\\TEMP\\testfolder \\”, NULL);
    RemoveDirectory(“C:\\TEMP\\testfolder \\”);
    return 0;

Examples on how to delete trailing space folders from the console.

C:\>rd c:\temp\testfo~1
C:\>rd “\\?\c:\temp\testfolder ”


The desktop.ini is a standard text file that can be placed in any Windows folder to customize certain aspects of the folders behaviour, i.e. what the folder icon should be, what folder name to display, etc. The desktop.ini file is normally a hidden file so to display existing ones in folders you’ll need to make it visible by opening the folder and clicking on the Tools menu . . . Folder Options and selecting View. Then select “Show hidden files and folders” radio button and also uncheck “Hide protected operating system files (Recommended)”. Below I have touched upon three customised folders and the ini files it contains.

For Favourites folder the folder has to have attributes of either readonly or system or both for the folder to change to “favourites” from the actual folder displayed in Explorer. The desktop.ini file can have any attribute and below is an example of the ini file.


The LocalizedResourceName parameter can be used to change the folder name to something else when viewed in Windows Explorer.

Certain system folders use class ids to define the folder properties. Here again the folders attributes define the folder properties and the desktop.ini file can have any attribute set.

To create a recycle bin folder changing the folder attributes to system or readonly makes it change to the bin icon. The ini file settings should contain this class id below


For the Scheduled tasks again changing the folder attributes to system or read only makes it change to the tasks icon.


So what does this mean from a malware point of view? Well these kind of system folder properties malware files can be easily hidden from view. i.e. having a job in Windows tasks (C:\WINDOWS\Tasks) with a hidden attribute set on the job file will be invisible even with all files and folders set to show. The same goes for the recycle bin where malware writers create a bogus recycle bin folder containing malware files which when browsed through Explorer remains invisible and only genuine deleted files are shown to the user.