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].'"
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.
Yeah, because all self-respecting coders has this driving urge to reinvent the wheel whenever they're met with an already functional and documented piece of code.
Bad idea. That would likely create more problems than it solves and bring back the worst of DLL hell, especially for frequently updated and used DLLs and also given how badly certain vendor's individual development teams seem to communicate with each other. Say App_A installs v1.0.1 of a DLL in a shared location, then later App_B then comes along and updates this to v1.0.2 - congratulations; you just broke App_A. OK, there's a fix for that, but only if you can call the awful kludge that is WinSxS a "fix".
UNIX? They're not even circumcised! Savages!
Yeah, and what happens when that DLL gets updated due to a different vulnerability, but the app doesn't? You either get a broken app or one using an insecure library *anyway*.
Microsoft created a liberal dynamic library search path that allows (or even encourages) applications to not fully specify DLL locations. Now, after the fact, they publish this security statement saying not to use the dynamic library searching they documented previously. It is of course Microsoft's fault. They didn't consider security at all when loading DLLs, and now they are blaming applications that implemented the documented specification.
The bottom line is that Windows was never designed to be secure, it was designed to have the most functionality, and trying to patch every hole now is almost impossible. Generally, when code reaches this level of complexity and brittleness, it is often the best course to start all over.
I agree - it's unclear to me what the "fault" of the developer is here, and which applications are at fault. I thought that loading a DLL by name without a specific path was standard practice? And how does it work with linking - in my experience, all applications I've written and used can either use a DLL in the standard path, or be overridden by a local DLL, so surely that's standard practice too? And wouldn't this affect almost every Windows program that uses DLL?
But then, I'm not sure that this is a bad system anyway. Well, if it's possible to include a DLL loaded off a web page as being the standard path, that seems a gaping hole. However, if this flaw requires an attacker to already install a dodgy DLL in the user's path on their system, surely that would already be the security flaw? I mean, it's a bit like saying "It's a flaw that people can run exes by double clicking, there could be malicious code" - the flaw isn't in running exes, the flaw is how they got there in the first place.
What is the proposed fix for applications that link to DLLs? And how do other operating systems work - again, I thought that having a path system allowing multiple possible locations for shared libraries wasn't uncommon?
MOD PARENT UP !! Fact is, on any unix out there, no competent admin would leave '.' neither in executable path, nor in dynamic library search path. It's another of case of a security hole known at least theoretically since the 60's, and observed in real life in the 80's, that microsoft overlooked in the design stage when it was time to follow proper security assessments, and are now stuck with.
They should be put on trial for dumb blunders like this one. When you hire top professionals who can't ignore the 'state of art' when doing an error like this, it should be considered a cause for limitless civil liability.
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.
Ummmmmm; "According to Moore, at least one Microsoft executable -- "explorer.exe," the Windows shell -- includes the flaw."
I'm pretty sure your Windows machine has explorer.exe loaded by default.
Some bring out the best in others, some the worst. Some bring out far more.
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).