Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: DLL hijacking vulnerabilities - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
DLL hijacking vulnerabilities

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 :(

DLL hijacking

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.

--
Bojan
INFIGO IS

I will be teaching next: Web App Penetration Testing and Ethical Hacking - SANS Riyadh October 2019

Bojan

381 Posts
ISC Handler
Running as non-admin (and installing apps in directories not writable by non-admins) should protect users from inadvertently downloading DLL's into all subdirs *except* the "current directory" (which is a per-application-instance path to "the" working directory). Perhaps I'm missing the point, but I see no reason whatsoever to include the working directory in the DLL search path, as it varies and thus will lead to unpredictable results (what parts of the DLL hell does Microsoft refuse to fix).

Note that, IIRC, this is not a plain remote execution bug; users will have to be tricked into downloading DLL's to specific directories. However using standard Explorer settings, DLL's are typically not visible so users may not be aware of potentially planted "bombs". I recall the "Safari carpet bomb" issue where DLL's were planted on the user's desktop without asking any questions (however that bug should be fixed by now).

Anyway Microsoft should probably update system files such that something like a "ReallySafeDllSearchMode" registry value is supported, and the "current directory" is not included in DLL searches at all.

Until Microsoft provides a fix, another approach may prove useful, that is, by simply adding the missing DLL's to a location searched *before* the current directory. Obviously you must first find out which DLL's those are (for all applications you use), and, secondly, you'll typically have a problem locating those missing DLL's... A solution and a workaround are provided below.

DEPENDENCY WALKER

The excellent tool "Dependency Walker" (aka depends.exe) written by Steve Miller is quite useful for said purpose. It lists all DLL's searched for at application startup, and tries to identify dynamically loaded DLL's (at a later stage). Depends.exe was distributed with various Microsoft applications (such as the "XP SP2 Support Tools" that are still on my system). Note that if Process Explorer (by Mark Russinovich) finds depends.exe on your system, right clicking an executable will show a submenu containing "Launch depends...".

You can download the latest version of DependencyWalker at http://www.dependencywalker.com/ . None of the files in the x86 version I just downloaded was digitally signed. Somebody else had already submitted the x86 zip to http://www.virustotal.com/file-scan/report.html?id=03d73abba0e856c81ba994505373fdb94a13b84eb29e6c268be1bf21b7417ca3-1282559314 which yields 0/41 (however, this neither means that Steve Miller can be trusted, nor that Steve Miller actually created or last-modified the files included in the zip file). You may want to search the Microsoft site for a more reliable (and digitally signed) but older version. Anyway be sure to read Steve's FAQ, http://www.dependencywalker.com/faq.html , in particular the topmost question (and answer ;)

SERVMESS.DLL

Back to the second problem at hand: any DLL that an application looks for, that is *not found*, apparently poses a potential security risk. However, if the application functions perfectly without it, chances are that the application will still function correctly if you *add* a dummy DLL to the application installation directory with the missing-DLL-name (however, without the rquired functionality). For example, SERVMESS.DLL that comes with the W2k3 resource kit support tools (as part of the AutoExNT service) doesn't include any interesting code; instead it contains strings intended for various eventlog messages. The idea is to use a DLL without functions in order to avoid accidentally called functions, which may either take place based on the function-NAME (there's a small chance that function names coincide) *or* based on the function-NUMBER (ordinal) in the DLL (huge chance of conflicts). Calling a function with a wrong number of parameters and/or different parameter types usually causes an application to crash (and may even introduce other security vulnerabilities). My guess (but I'm not 100% sure, don't blame me if it happens too you) is that SERVMESS.DLL won't cause any crashes. Side note: the original SERVMESS.DLL that came with the NT4 resource kit, obviously as a result of a bug, didn't even contain any strings...

The W2k3 x86 reskit tools can be downloaded here: http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en
Unfortunately I'm unaware of a similar 64bit DLL, but then, I'm not sure that this problem even applies to 64-bit Windows.

CALC.EXE

As a test I opened c:\windows\system32\calc.exe in depends.exe: it reported (in red) that IESHIMS.DLL and WER.DLL are missing. I copied servmess.dll to C:\Windows\System32\iEsHImS.DlL and C:\Windows\System32\wEr.DlL (I used the funny names to be able to easily relocate those "hacked" files :)
I had to close and restart Depends.exe, now it reports: "Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module" which is logical, servmess.dll doesn't include the functions that the application is looking for.

Actually it's not CALC.EXE that needs IESHIMS.DLL and WER.DLL: it's IEFRAME.DLL which is part of a rather deep hierarchy of DLL's. Furthermore, most Windows applications appear to be potentially looking for IESHIMS.DLL and WER.DLL sooner or later. I've not encountered any side effects after the change mentioned above - so far, but will post them here when I do. BTW I conducted this experiment on an English version of XP SP3 32bit (fully patched).

FINALLY

I suggest readers of sans.edu experiment with Dependency Walker to discover missing DLL's in the apps they use, perhaps "replace" them by dummy DLL's (until MS provides a fix), and report their findings.
Erik van Straten

122 Posts
Microsoft Security Advisory (2269637)
Insecure Library Loading Could Allow Remote Code Execution
- http://www.microsoft.com/technet/security/advisory/2269637.mspx
August 23, 2010 - "... DLL preloading attacks..."
.
Jack

160 Posts
Thanks to PC.Tech for the URL!

Indeed the fix described in http://support.microsoft.com/kb/2264107 introduces a new registry value "CWDIllegalInDllSearchValue" (not "ReallySafeDllSearchMode" I proposed, ya cant gettem all ;) that, if set to 0xFFFFFFFF, removes the current working directory from the default DLL search order.

IMPORTANT: using Microsoft's fix is the preferred solution over experimenting with SERVMESS.DLL as I described above as a workaround!
Erik van Straten

122 Posts
The text in http://support.microsoft.com/kb/2264107 seems not to be fully correct yet.

In the tables one can read "CWDIllegalInDllSearchValue" (which is what I mentioned in my post above), this is incorrect!

The value name I found in ntdll.dll (just patched on my PC) is "CWDIllegalInDllSearch". This matches the examples shown on the KB2264107 page, so they appear to be correct.

Furthermore (less important), the page mentions:

The CWDIllegalInDllSearch registry key [...]

which, IIRC, is incorrect, it's not a *key* but a registry value name (to which one assignes value data, in this case of type DWORD).

Finally, it appears that installing KB2264107 adds the value CWDIllegalInDllSearch to the registry, but sets it to zero (no effect). So, after patching, you'll have to assign other value_data (0xFFFFFFFF) to CWDIllegalInDllSearch in order to prevent the execution of DLL's in the current working directory.
Erik van Straten

122 Posts
I've discovered quite a few vulnerable programs that I haven't seen mentioned publicly yet that I would consider "high risk" (ie - they're part of the Windows core software). Two big ones are Outlook Express 6 and the Windows Address Book.

http://www.attackvector.org/new-dll-hijacking-exploits-many/

Erik van Straten
1 Posts
Looks like 0xFFFFFFFF breaks Outlook 2003 SP3, at least the first time it gets opened by a user (and that was the first app I tested)! This is going to be painful. I did some quick testing, and it looks like there is no option 3 (i.e. block both WebDAV and SMB, but permit all local working directory DLL loading). My hope was that the REG_DWORD was a bit-vector and 3 would represent flipping the WebDAV and SMB bits on, but that doesn't appear to be the case. ARGH! So now I have to decide which vector appears to be the more likely one since I can't protect against both.
Anonymous
Breaks Outlook 2002 (Office XP, fully patched) as well.

Apparently, during startup, Outlook (temporarily?) sets "C:\Program Files\Common Files\System\Mapi\1033" as its current working directory in order to load DLL's such as OUTEX.DLL, EMSMDB.DLL and MSMAPI32.DLL.

Fix: run regedit, locate key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE", open the value "Path" and append to it:

;C:\Program Files\Common Files\System\Mapi\1033

NOTE#1: The "1033" subdirname applies to US English, a different value will likely apply on systems with other languages in use.

The full value data on My PC now reads:
C:\Program Files\Microsoft Office\Office10\;C:\Program Files\Common Files\System\Mapi\1033

NOTE#2: the "Office10" subdir applies to Office XP (2002), this will probably be "Office11" for Outlook 2003.
Erik van Straten

122 Posts
Whoops, this site removes sequences such as \ followed by 10.

The string to append to the "Path" value in the HK.....OUTLOOK.EXE registry key LOOKS LIKE:

;C:/Program Files/Common Files/System/Mapi/1033

However, you must replace each / (slash) by \ (backslash) in regedit in order to get things right. Sorry I can't post the correct string here!
Erik van Straten

122 Posts
The patch breaks Chrome. When opening Chrome, it says it cannot find the file avutil-50.dll .
Patk7

9 Posts
I can verify the Chrome error, I get the same thing.
Patk7
3 Posts
MS has published KB 2389418
http://support.microsoft.com/kb/2389418
addresses the dev community but not the users. Looks like a lot of apps will be needing patches... and a lot are going to stay un-patched too.
Michael

32 Posts
Personally, I am tired of you "security" people trying to force MS to make Windows a perfect little cream puff. I personally think the carriers need to do more stopping the crap from leaving their perimeters. If the eventual fix to this breaks everyones apps, I see the day after updating being a day of rebooting for sure, the reboot required for System Restore to send the thing back a day .... I will be.
Greg

25 Posts
Hi there,
playing on my notebook with dllhijacking tool I have found that CyberLink products installed on are vulnerable to this threat. Reading on the corporate web site of CyberLink, seems that they have spreaded their products to notebook vendors. They speak of milions of license distributed in the world. If you are interested for more details check: http://extraexploit.blogspot.com.
The problem is: how many 3rd party software vendor that spread software in notebook default installation are impacted by this threat in the world ?
Greg
1 Posts
Thank you very much for this info, both ISC and the comments. I was on vacation for a week and would have missed all this.
Chris

1 Posts
It appears the MS Tool does not actually add the CWDIllegalInDllSearch registry value, rather it just updates the .dll's outlined in http://support.microsoft.com/kb/2264107 . Can someone verify this on their systems. I tested the update on XP SP3 and Win 7. Manual creation of the registry key seems to be needed.
Tim

9 Posts
I can confirm that KB2264107 does not add CWDIllegalInDllSearch to the registry, my bad that I wrote the contrary above, sorry!

Initially http://support.microsoft.com/kb/2264107 mentioned "CWDIllegalInDllSearchValue" in each of the three tables at the top. That didn't work so I experimented, and somehow CWDIllegalInDllSearch=0 showed up, so I presumed it had been there all the time (it looks like that, if the value name existed and you rename it, ntdll.dll *restores* the original value name from memory).

However, note that, according to Microsoft, there's no functional difference between CWDIllegalInDllSearch=0 and no CWDIllegalInDllSearch value at all.

Furthermore I can confirm that changes to CWDIllegalInDllSearch are effective instantaneously (no reboot necessary); changing CWDIllegalInDllSearch from 0 to 0xFFFFFFFF works immediately (you can even keep regedit open).

My apologies for any confusion I may have caused.

@tired (Thu Aug 26 2010, 01:26): more than 12 years ago the NSA published a report how to secure NT, see http://packetstormsecurity.org/NT/audit/NSAGuidePlus.PDF (source: http://www.h-online.com/security/news/item/Microsoft-warns-of-DLL-vulnerability-in-applications-1064584.html).
Page 103 of the PDF explicitly warns for 'The "." Issue'. Microsoft _could_ have decided to warn programmers that with the introduction of XP, DLL-searching in CWD would be deprecated. Like in many similar cases MS decided not to listen to security experts, resulting in the crippled mess called Windows today.
Erik van Straten

122 Posts
@tired @Erik van Straten I am inclined to agree with Erik here. Having been a former programmer on the Windows platform, generally speaking, coders will often use shortcuts if given to them. The fact that there are several MS apps affected by this bug screams MS was not doing a decent job of documenting the issue. Really it's about backward compatibility of 3rd party apps, but at some point it should have been deprecated.
Tim

9 Posts
As an appliation developer on Windows, I can say that this is going to be a nightmare.

One thing that some of you have missed is the concept of "delay loading" that Microsoft supports. The idea is that you have a reference to a dll that does show up in depends, but it doesn't actually try and load the dll until such a time that the dll is needed. This can be useful for circumstances where the dll might not always be available, and it can also help in circumstances where the functionality is rarely used, and you don't want the overhead of initialization of those dlls in your application. In depends, those dlls show up with little hourglass icons next to each dll.

I was fiddling with my Android phone the other day, and I was noticing that many partitions on the phone were mounted with the "noexec" flag set. I can't put an executable on the SD card for example. If they didn't do this, you could easily hack the thing to make some file SUID and bypass all of the security on the phone (yeah - it is VFAT as well, which wouldn't let you do this). That seems like an incredibly useful feature for something like this, but Windows does not have the ability to mount a sharepoint with a "noexec" flag.

I had never even heard of the WebDAV stuff until this came up - that's not the type of functionality that we have any interest in with our applications. The whole thing sends a chill up my spine - who in their right mind designed that stupidity?
Eric

43 Posts
@tired @Erik van Straten I am inclined to agree with Erik here. Having been a former programmer on the Windows platform, generally speaking, coders will often use shortcuts if given to them. The fact that there are several MS apps affected by this bug screams MS was not doing a decent job of documenting the issue. Really it's about backward compatibility of 3rd party apps, but at some point it should have been deprecated.
Tim

9 Posts
We've set CWDIllegalInDllSearchValue=ffffffff in CurrentControlSet. Afterthat Outlook is brocken (see above). But also Sendto in word, excel, powerpoint, .. does not work anymore.
We add the path
;C:\Program Files\Common Files\System\Mapi\1033
to
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\winword.exe", ...excel.exe", ...
like above an it work fine.
Tim
1 Posts

Sign Up for Free or Log In to start participating in the conversation!