Slashdot Mirror
Windows DLL Vulnerability Exploit In the Wild
WrongSizeGlass writes "Exploit code for the DLL loading issue that reportedly affects hundreds of Windows applications made its appearance on Monday. HD Moore, the creator of the Metasploit open-source hacking toolkit, released the exploit code along with an auditing tool that records which applications are vulnerable. 'Once it makes it into Metasploit, it doesn't take much more to execute an attack,' said Andrew Storms, director of security operations for nCircle Security. 'The hard part has already been done for [hackers].'"
This is actually faulty programming in applications, not Windows. Kind of like buffer overflows. It's what happens when you don't know what you're doing nor are you following secure coding standards.
Because application developers, not Windows, are to blame, Microsoft can't patch the operating system without crippling an unknown number of programs that run on the platform.
There are no reports of any Microsoft or default Windows applications containing the bug, so unless you have a specific third party app you're not vulnerable. Also, there is already a tool available from Microsoft you can use to block it from all applications, but some of the apps might obviously break.
To protect from stupid developers you would probably need something like selinux for Windows, but considering how much pain in the ass it is on Linux too, it wouldn't really work for all the casual people. However, moving applications from languages like C/C++ to languages like C# can help just like with buffer overflows. At least it provides extra layer of security against clueless programmers.
There are no reports of any Microsoft or default Windows applications containing the bug
Really? That's odd, from the original blog posting:
At least four of Microsoft’s own applications have been confirmed as exploitable through this vector, two of which were already being addressed by the time I contacted them.
My work here is dung.
From the Microsoft FAQ:
How could an attacker exploit this vulnerability?
This vulnerability requires that the attacker convince the user to open a file using a vulnerable program, from a remote network location. When the application loads one of its required or optional libraries, the vulnerable application may attempt to load the library from the remote network location. If the attacker provides a specially crafted library at this location, the attacker may succeed at executing arbitrary code on the user's machine.
I don't know about you, but I never open files from an untrusted SMB...
Well, fully qualified doesn't mean static. You could compute the fully qualified name at runtime to pass to the LoadLibrary call. Or you could just stick a SetDllDirectory call somewhere in your app startup and keep the rest of the code the same.
It's not replacing. It's you, as a developer, saying "try to load foo.dll", without specifying where "foo.dll" is to be found, but relies on the OS to find it for you. It traverses a list of possible locations, and as a last resort tries the current working directory.
The problem is all yours if you don't specify where the OS is to look for the DLL. If you want to load DLLs from %installdir%\dlls, then all you have to do is specify that path. It's not rocket science.
And no, allowing DLLs to be loaded from remote locations isn't stupid, as it allows for shared installations, which both saves boatloads of disk space, and allows for updating a single place instead of on each machine.
Not considering that possibility is what's stupid.
And not understanding how the DLL loading and file systems work on the OS you program for is even worse.
Finally, the exploit doesn't depend on a remote share either -- that's Smallsquishy's damage control PR department working overtime. If you download a zip with hundreds of MP3 or picture files, extract it, and double-click one of them, the DLL that was in the archive will get loaded if your default player/viewer queries for that DLL without specifying a path.
It's not a new exploit either -- it's been around for a long time on Windows. And before that, there were vulnerable Linux systems with "." in LD_LIBRARY_PATH, which basically amounts to the same thing.
I took me a while to figure out how this exploit works, but I think it goes like this:
I have an application, foo.exe, that can make use of an optional system component (or 3rd-party DLL), bar.dll. I don't ship that DLL, and I can't guarantee that it will be present on every user's system. So to ensure that my program degrades gracefully, I open it with LoadLibrary("bar.dll"), and if it's not found I disable the features that depend on it. Since it's not my DLL, I can't speculate on where it's installed, so I use an unqualified path and let the loader do the searching (this is, after all, the job of the loader). The ensures that, as long as bar.dll is correctly installed on the system, my application will find and use it.
From an application developer's point of view, this the right way to do things. If I did this on Linux or MacOS, it wouldn't be a problem. Unfortunately, Microsoft decided that the current directory (".") should be in the default search path (see http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx ). It's even searched before $PATH!
Now the exploit goes like this: .\bar.dll and load it into the unsuspecting foo.exe.
1. On \\evilserver\evilsmbshare, I place a file foofile.foo, an extension which is associated with foo.exe. Right next to it, I create an evil version of bar.dll.
2. I convince the user to double-click on foofile.foo, causing windows to open foo.exe, with a current directory of \\evilserver\evilsmbshare.
3. If the user's system doesn't have bar.dll installed, Windows will eventually find my evil version of it at
4. My evil code runs and does whatever evil deeds I want it to.
If this is correct, then the decision my Microsoft to put the current directory in the library search path seems pretty braindead, and it's hard to blame application developers for assuming that LoadLibrary() will load a library in a sane and secure way. But I'm having a hard time imagining an application that would break if the current directory were just removed from the search path. Shipping DLLs in the application directory is common practice, but expecting them in the current directory? Why would you do that?
It seems that this exploit requires you to trick the user into opening a file from a filesystem you have access to, at which point you could probably just as easily get them to open a trojan directly. I think local privilege-escalation attacks are more probable (e.g. tricking a system service into opening your evil DLL).
Or, correction, the good DLL would have to go into a folder that is in the PATH and not in any of the higher priority system folders. And you would have to register a file handler and a new type... since the directory of the EXE has first priority. Oh well.
The priority list goes:
1. The directory from which the application loaded
2. The system directory
3. The 16-bit system directory
4. The Windows directory
5. The current working directory (CWD)
6. The directories that are listed in the PATH environment variable
And the patch + adding the new reg value disables #5.
The whole fix should be rolled up into a little switching program. We should not have to edit the registry to fix this vulnerability. And we should be able to turn the fix off easily if it causes problems.