Microsoft published an article yesterday about DLL Preloading on TechNet.

The basic premise behind a DLL Preloading attack is simple: unless you explicitly set the paths to your DLL files they might be loaded from the current directory. That current directory might contain a file called “xyz.dll” which will then get included into your process instead of your original “xyz.dll” file from your installation directory.

This is a class of vulnerabilities that affects a wide range of applications, but the severity of these have so far been considered local and low impact.

It seems that Microsoft have been made aware of a remote attack vector that allows you to exploit DLL Preloading from a webpage.

The TechNet article does not mention what that attack vector is, so for the sake of debate I will highlight the most logical steps you will need to perform to remotely exploit DLL Preloading without any user interaction other than visiting a website :)

  1. Get user to visit malicious website
  2. Malsite contains an IFRAME pointing to an SMB/WebDav share
  3. The share contains a non-malicious file which can be automatically opened without warnings, such as an .JPG or .DOCX file, as well as a malicious file called “xyz.dll”
  4. The non-malicious file is then automatically opened through clickjacking
  5. The local process responsible for handling the non-malicious file, such as word.exe, is launched and starts looking for its DLL dependencies, such as “xyz.dll”
  6. The current working directory is set to the malicious share because the non-malicious file was opened from here
  7. Unless explicitly handled by the local process, “xyz.dll” will be included from the current working directory, the malicious share, the contents of which is controlled by the attacker

The only reason I am not giving this post the title of 0-day is because this has been known for some time and I have not bundled this as an exploit for you – I am on my way to work right now :)