Windows DLL Vulnerability Exploit In the Wild 178
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].'"
Re:Not quite (Score:5, Insightful)
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.
Re:Application developers fault (Score:5, Insightful)
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".
Re:Not quite (Score:4, Insightful)
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.
Re:Application developers fault (Score:5, Insightful)
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*.
Re:Application developers fault (Score:1, Insightful)
Nice reasoning there. Take a seat next to the tea party morons and the birthers.
This exploit compromises the application and needs elevation of privilage to root the OS. If your application runs as an administrator or system, you can be toast. Else only your user account can be compromised.
It is common practice for shitty programs like ITunes on windows to run a service as the system and do other crap they have no business doing. More surface area + unnecessary elevation of privilege = hacker poodu.
Re:And Also Four of Microsoft's Applications (Score:5, Insightful)
Re:Application developers fault (Score:5, Insightful)
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.
Re:Not quite (Score:3, Insightful)
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.
Microsoft's OWN fault !! (Score:5, Insightful)
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.
Re:wait, open a remote file through SMB ? (Score:3, Insightful)
Egress filtering at the perimeter FTW.
Now consider that the same exploit also works over WebDAV (which basically is just glorified http...), and suddenly egress filtering starts looking rather blunt against this threat...
Re:Application developers fault (Score:3, Insightful)
That would defeat much of the purpose of using DLLs.
Not to mention what would happen when Microsoft updates a DLL, or the user runs a rebase.
To top it off, it's more complex than the real fix too.
Re:Application developers fault (Score:1, Insightful)
That doesn't work if the DLL is already loaded on behalf of the other application. You'll get that version, too.
Re:Application developers fault (Score:4, Insightful)
Or you place v1.0.1 of the DLL in the same folder as App_A.exe. App_A will find v1.0.1 of the DLL before going to the shared location *IF* it's written properly
What's the point of having shared libraries if only the application itself can load them, and can only load single, checksummed version of it?
In "MSI packaging Land" this is called "Application Isolation".
In the rest of the world we call it 'static linking' :-P
the problem (Score:1, Insightful)
`2. If the application tries to load a DLL whose name consists of a NULL, it will search for a file named ".DLL [metasploit.com]". This is exploitable in most cases and affects at least one Microsoft product.'
Re:Not quite (Score:3, Insightful)
Yup, the general population repeatedly bending over to big corp budgets sounds like real life to me.
Re:Not quite (Score:4, Insightful)
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.