For the last couple of days there have been a lot of discussions about a vulnerability published by a Slovenian security company ACROS. HD Moore (of Metasploit fame) also independently found hundreds of vulnerable applications and, as he said, the cat is now really out of the bag.

In order to see what is going here we first have to understand how modern applications are built. Modern applications come modularized with multiple DLLs (Dynamic Link Libraries). This allows the programmer to use functions available in other DLLs on the system – Windows has hundreds of them. Now, if a DLL is not available on the system, the developer can decide to pack it with the main application’s executable and store it, for example, in the applications directory.

The most important DLLs are specified in the KnownDLLs registry key (HKLM/System/CurrentControlSet/Control/Session Manager/KnownDLLs). These are easy – if an application needs to load it, the system knows that they have to be in the directory specified by the DllDirectory registry key, which is usually %SystemRoot%/system32.

However, when another DLL is being loaded, the system dynamically tries to find the DLL. Historically, Microsoft made a mistake by putting the current directory in the first place (some of you Unix oldies might remember when “.” was at the first place in the PATH variable). This has been fixed by Microsoft by introducing the SafeDllSearchMode setting (registry value). This setting specifies the order in which a DLL will be searched for. For example, as specified in http://msdn.microsoft.com/en-us/library/ms682586%28v=VS.85%29.aspx this is the search order with the SafeDllSearchMode setting enabled:

   1. The directory from which the application loaded.
   2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
   3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
   4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
   5. The current directory.
   6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

If multiple directories hold a DLL with the same name, the first match wins. This setting is enabled by default on Windows XP SP2.

Now, the problem happens when, for example, the application tries to load a DLL that does not exist on the system. You can see one such example in the picture below, where I found out that one of my favorite applications is very much vulnerable. See how it tries to find the DLL in all those directories before if gets to the one on the share? Both names of the application and DLL have been blacked out – no point in serving this on a silver plated dish :(

Ok, so what about attack vectors. Any place where the attacker can put both the file to be opened by an application and a malicious DLL can be used as the attack vector. Obviously, as in the example above, the most obvious attack place are Windows shares so I guess we are looking at another vulnerability that uses similar attack vectors such as the LNK vulnerability last month – the difference here is that by just browsing to the directory nothing will happen since the user has to open the file.

In order to protect your networks/system be sure to audit permissions on shares to prevent unauthorized users from putting files where they shouldn’t be. Of course, I expect that by now you already blocked SMB and WebDAV on the perimeter so an external share cannot be used.

What about a fix? This will be a difficult one, especially since we can look at SafeDllSearchMode as a fix. So in most cases, developers of vulnerable applications will have to fix them and judging by the numbers I’ve seen around we are looking at a very difficult period. Hopefully those popular applications (such as the one I successfully exploited above) will get patched quickly so the final risk will be reduced.

We will keep an eye on this and update the diary as we get more information.

UPDATE

Microsoft released several articles describing details about this vulnerability as well as offering some workarounds. The main security advisory is available here (2269637). Recommendations are basically similar to those I wrote above, however, Microsoft also released a tool that allows blocklisting certain directories (locations) from being used for library loading. You can find more information about the tool here, and the tool itself here. The tool adds a new registry setting called CWDIllegailInDllSearch. This allows you to block loading of DLLs from shared network disks or through WebDAV clients. Of course, if you plan on deploying it, I recommend thoroughly testing it before push it somewhere as it might break loads of things - that is probably why Microsoft doesn't push this as a security update. To be fair, this is not Microsoft's fault, but bad programming since this vulnerability has been known for years and years (although some new attack vectors have been published recently). Microsoft also released a nice document about searching DLLs that you can find on the second link above (I especially like how they used Process Monitor to demonstrate the vulnerability and removed the vulnerable application's name and the DLL it's loading - same as I did in the picture above :).

Finally, I would like to say thanks to readers who wrote in, especially to Stefan Kanthak who shared a whole list of possible attack vectors. After spending some time going through this and locating even more, this looks extremely bad, but it is questionable if we will see wide exploitation of this vulnerability.

Let us know about your experiences with this and especially if you see someone/something exploiting this.

UPDATE 2

We received some e-mails about active exploitation of this vulnerability in the wild. While there are potentially hundreds, if not thousands of applications that are vulnerable, it appears that the attackers so far are exploiting uTorrent, Microsoft Office and Windows Mail, which are, coincidentally or not, applications for which Proof of Concept exploits have been published. Remember, it is extremely easy to exploit this and it doesn't require any advanced knowledge so be sure to check Microsoft's recommendation above or be very careful about files you open from network shares.

UPDATE 3

US-CERT has released an advisory regarding this issue today. As far as I can see there isn't any new information as such.  The latest version of the bulletin can be found here http://www.us-cert.gov/cas/techalerts/TA10-238A.html  - MH

--
Bojan
INFIGO IS