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.
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.
Releasing these exploits mostly helps who is best equipped to use them. Malware-biz and Microsoft. Should just write some stuff to share all data files in p2p networks and let it run.
Build your own energy sources from scratch. http://otherpower.com/
The exploit requires user action. So the exploit isnt going to be as bad as it could have been.
This strange belief that doing things "the hard way" is in some unfathomable way "better" has always been interesting to me.
A self-respecting coder is a strange beast indeed if it acts the way you describe it doing. A competent coder would just use any tool it has access to (including metasploit) in order to achieve its goals. A nice, competent coder would use this tool or any other to check the applications he uses or writes for security holes. Ignoring this tool because it's "too easy" is stupid.
And regarding those "self-respecting coders", I don't think they intersect much with the kind of malicious hackers who would be willing to use this exploit for nefarious reasons.
If he explores all forms and substances Straight homeward to their symbol-essences; He shall not die.
Microsoft issues a patch. This conversation follows:
Customer: Hey. This app stopped working. What gives?
Support: Yeah, Microsoft issued a patch which broke it. It's Microsoft's fault that they have a buggy OS.
C: Hey Microsoft, what gives with this patch breaking my app?
Microsoft: The code used by that app was vulnerable to exploitation. We fixed it. You developer used code which was exploitable and will need to fix it.
C: Hey, Microsoft say they made my PC more secure with this patch. Apparently your rubbish code was exploitable. You knowingly sold me software which had a vulnerability which could result in serious security issues? Shit, I hope your legal team is well paid.
S: A patch is on the way. Please don't sue.
Finally had enough. Come see us over at https://soylentnews.org/
"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.
I'd like to introduce you to Dan Bernstein, creator of QMail and DJBDNS.
Certainly, he could've accepted that BIND, Sendmail and Postfix were functional, but what fun would that be?
Even if Dan isn't self-respecting, I'm sure there are many (myself included) that respect him.
"Lame" - Galaxar
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...
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...
You knowingly sold me software which had a vulnerability which could result in serious security issues?
S: A patch is on the way. Please don't sue.
Meanwhile, in the real world...
in an "open" LAN environment: an exploited machine sets up a share, emails links to others in the contact list, remote exploit ensues. But who's allowing egress (outbound) SMB, WebDAV (at least not to a whitelist of remote hosts) on their network? Putting Windows Firewall up on all the workstations to drop ingress SMB traffic (with a few host exceptions for those pushing out updates via SMB) would be a smart thing to do as there's really no reason for workstations to be sharing files in a network with file servers.
body massage!
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.
Really? Phewww! I thought I was among few paranoid enough to not trust anything I haven't implemented myself from scratch. Good thing to hear all self-respecting coders work like that and I am not a minority! I mean, it was kind of obvious, how can you trust a library or sample code some unknown guy wrote when you yourself, the master developer, can do the optimal implementation yourself.
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
I think the post above was intended for this article...
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...
Um, that’s why they have the %programfiles% environment variable, and it’s why you install applications there, and it’s why the current directory when you launch a file (%userprofile%\Default\Documents\) should never be where you’re getting executable content (such as a .dll file).
When you launch a file via its shell extension, the “current” directory and the directory where the executable is located which opens that file type are not the same... and you shouldn’t be looking in the current directory for your .dll files. Period.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
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.
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.
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?
2 letters: NO
as in NO, that doesn't do anything to fix this.
AccountKiller
The problem is that in attempting to load a remote media file, the application is tricked into loading a malicious DLL located in the same directory as the media file.
`2. If the application tries to load a DLL whose name consists of a NULL, it will search for a file named ".DLL". This is exploitable in most cases and affects at least one Microsoft product.'
But if it's true that the folder of the data file is included in the search path for DLLs (as opposed to the folder of the application), isn't that something that Microsoft should fix?
How would an application developer fix it to avoid this problem, whilst still allowing the possibility of loading DLLs from the application folder (honest question, I'm not saying it isn't possible, just curious of the solution)?
Do you know how things work with linking the usual way with a lib file (as opposed to manually calling LoadLibrary)?
In our polytheism world we can have multiple gods, so we have a secure OS that can run QMail and DJBDNS
Disclaimer: This opinion was created without the use of any facts
> Here, I fixed it for ya. No self-respecting coder would use a library like that.
Why? Are there bad bugs or security exploits in that library?
Idiots continue to put up with the "release now, fix later" model of software development? Continue to have sub-standard produce foisted upon them because an application isn't a product you can hold, and therefore has gotten around merchantability laws on a technicality?
Yup, the general population repeatedly bending over to big corp budgets sounds like real life to me.
Finally had enough. Come see us over at https://soylentnews.org/
Its not the rewriting that is important. It is the deconstruction and reconstruction from scratch that is important. If you pour over a piece of someone else's code, document it, talk about it, sleep with it, whatever, you still will not be as intimately familiar with the code as someone who wrote it.
There is absolutely nothing wrong with starting with someone else's well documented piece of code, reverse engineering it, and implementing a "inspired" version of your own. It goes a long way to understand problems you would never get a chance to understand.
Think about it this way, all sorting algorithms have been written a million times. Still, students have to struggle through implementations every semester so they learn. This is the same thing. Its not wasting time, it is improving oneself.
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).
I mean, it was kind of obvious, how can you trust a library or sample code some unknown guy wrote when you yourself, the master developer, can do the optimal implementation yourself.
Translation: "I am a better program than any other programmer on Earth." Yeah, right.
The WebDAV issue is a much more severe problem, but it has been known and circulating for many month now and isn't a new problem, the hidden service (it doesn't show up in services.msc) can be disabled by setting a value in the registry.
Mmm, secret, hidden, insecure services which can only be disabled by magic registry settings.
It's so long since I've used Windows much that I'd completely forgotten what a security nightmare it was.
It does, but this has nothing to do with buffer overflows. Please RTFA.
AccountKiller
Since when is does this exploit involve overflowing buffers?
cat:
. Is there still a reason why we should keep adjusting our concept of time according to what the earth does?
Like, duh... otherwise, in 260 million years, Christmas will be in the middle of the summer. That will fuck up Santa's ride!
Have you updated your kernel lately?
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Has anybody written a test to verify that Microsoft's fix has been properly applied? It would be a simple DLL with that pops up a message, and simple EXE that loads the DLL (which has new unique name). Or even two versions of the DLL, one with a good message and one with a bad message. One goes in the system path, one goes in the same path as the EXE, a temp folder.
The MS kb patch has one typo, you add a new DWORD value to the registry, not a new key.
http://support.microsoft.com/kb/2264107
MS fixed the other typo mentioned here:
http://isc.sans.edu/diary.html?storyid=9445
Thank God, I mean we've got hundreds of thousands of servers out there tasked with running QMail and DJBDNS, now we can rest assured they're all secure.
This is truly a good day for the hordes of IT people dutifully running all those QMail and DJBDNS instances!
Like duh! Christmas IS in the middle of summer in some parts of the world.
If all software had to hold up to merchantability rules, it would cost orders of magnitude more than top-of-the-line hardware and flaws would *still* exist. Hospitals, banks, governments, etc. pay a minimum of hundreds of thousands of dollars for this sort of software, usually for very specific hardware that's been explicitly and thoroughly tested, and the payback is marginal at best. In other words, be careful what the fuck you wish for.
https://www.eff.org/https-everywhere
If you pour over a piece of someone else's code, document it, talk about it, sleep with it, whatever, you still will not be as intimately familiar with the code as someone who wrote it.
The fact that I can't remember what I wrote last year, let alone how I wrote it, is incontrovertible evidence to the contrary.
https://www.eff.org/https-everywhere
Signed binaries.
The app can verify the signer is the original author and not load it. You make some sort of general localized signer that will pass the 'trust' test for every binary so the user can override it as needed, like to replace a DLL with their own hacked version.
Give some sort of way to disable the signing check on a per app basis, that has to be done by the user, probably via UAC. Don't give any way to disable it globally or any way that it can be automated.
People will still be able to do all they need to do, but apps will have to be signed or they'll be too much of a pain in the ass for users to waste their time on them, and in a pinch you CAN still get around it.
Of course, all of this is just to protect users from themselves essentially since by the time you've got someone loading EXEs from untrusted sources, there are probably easier ways to have you're way with them.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Hand in your geek card as well.