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 far from a fence post bug, or a buffer overflow. This is more like either DLL injection, or like the paragraph alludes to replacing a DLL.
A simple fix would be for a programmer to have their app at initialization checksum any dll it uses.
I am Bennett Haselton! I am Bennett Haselton!
How much fault is really debatable. Yes if an application is coded in a such a way that the exploit exists that's partly on the fault of the programmer; however, why should that translate into an exploit on the OS? Also from what it appears, many applications have this problem including some from MS so it does not appear some obscure programming quirk.
According to reports that first appeared last week, developers, including Microsoft's, have misused a crucial function of Windows, leaving a large number of Windows programs vulnerable to attack because of the way they load components.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Considering the failure of antivirus to protect the first victims of any new virus it looks like that may have to be the way to keep the platform viable. A list of what is allowed provides far better protection than an ever changing list of what is not allowed.
"but considering how much pain in the ass it is on Linux too, it wouldn't really work for all the casual people."
I have Fedora 12 on my desktop with SELinux enabled. I didn't have to do ANYTHING AT ALL. I haven't seen an un-intentional alert in months. I was worried so I set one off myself just to make sure SELinux is still working, and yes it caught it.
Here's what Microsoft recommends:
"Wherever possible, specify a fully qualified path when using the LoadLibrary, LoadLibraryEx, CreateProcess, or ShellExecute functions. "
"Consider removing the current directory from the DLL search path by calling"
In other words, they want programmers to use LoadLibrary("C:\program Files\my software\somedll.dll") instead of LoadLibrary("somedll.dll"). This is very counter-intuitive, as if you were app developer, you would want all of your DLLs be distributed with binary, and reside in same directory. Take a look in your program files directory, and almost every app does it that way...
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?
Microsoft can try to blame application developers for this, but it is definitely a Windows flaw. Linux and other Unix-like systems are quite secure without requiring developers to specify full paths to the locations of shared libraries. DLL's are no different in this regard. The problem is that, rather than using a separate variable such as LD_LIBRARY_PATH to specify the search path for shared libraries, Windows has always used the same search mechanism that it uses for executables: the contents of PATH and the working directory. It is the implicit inclusion of the working directory that is the problem. But they can't change it without breaking many (almost all?) Windows applications.
Even worse, consider visting a web page with <img src="file://maliciousSmbServer/share/test.jpg"> somewhere in it...
If the user's machine is compromised to the point where unauthorized dlls are replacing valid dlls that's not my problem as a software developer. The only validity to this bug is that windows allows dlls to be loaded from remote network locations (isn't this sort of stupid in the first place?).
I think the severity of this bug is blown out of proportion. The only idiots to blame is the idiot who did not secure his computer.
did you forget to take your meds?
You are assuming the "current directory" is set to the location where an associated file is located. That isn't true. When an application is invoked by an association the current directory is usually the location of the program executable itself, which is passed the fully qualified name of the file that was clicked and caused the invocation of the program.
So placing a DLL in the same folder as the associated file doesn't do anything. You have to put it in the same folder as the executable, which is (as of Vista and Windows 7) write-protected.
With XP it is a lot easier because the Program Files directory structure is not protected and it was common to have applications writing stuff there, so you couldn't protect it. As of Vista the rules changed and you can't write there anymore.
Yes, I understand the exploit. But again, if you have people dropping files willy-nilly into the file system you are going to have troubles. Same goes for Linux - if you install something that has setuser root it is pretty much an exploit for the entire system. Why would anyone do this? Because the installer tells them it is necessary and just does it. Same thing happens with Windows. If you aren't controlling what is installed, you aren't in control. Period.
Or you just sign it instead of hashing it. The net result being that you prove authenticity before blindly accepting a file.