Follow Slashdot stories on Twitter


Forgot your password?
Bug Microsoft Security Windows Technology

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].'"
This discussion has been archived. No new comments can be posted.

Windows DLL Vulnerability Exploit In the Wild

Comments Filter:
  • Re:Not quite (Score:5, Insightful)

    by Lazareth ( 1756336 ) on Tuesday August 24, 2010 @08:32AM (#33353504)

    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.

  • by Zocalo ( 252965 ) on Tuesday August 24, 2010 @08:38AM (#33353548) Homepage

    A simple fix would be for a programmer to have their app at initialization checksum any dll it uses.

    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)

    by jeffasselin ( 566598 ) <> on Tuesday August 24, 2010 @08:46AM (#33353614) Journal

    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.

  • by pelrun ( 25021 ) on Tuesday August 24, 2010 @08:49AM (#33353652)

    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*.

  • by Anonymous Coward on Tuesday August 24, 2010 @08:52AM (#33353676)

    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.

  • by Xacid ( 560407 ) on Tuesday August 24, 2010 @09:06AM (#33353814) Journal
    The link appears to be slashdotted, but my guess is that the emphasis from the parent is on "default". Microsoft offers more than just a standard vanilla OS install and applications.
  • by MojoRilla ( 591502 ) on Tuesday August 24, 2010 @09:08AM (#33353836)
    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.
  • Re:Not quite (Score:3, Insightful)

    by Ecuador ( 740021 ) on Tuesday August 24, 2010 @09:27AM (#33354066) Homepage

    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.

  • by Anne Honime ( 828246 ) on Tuesday August 24, 2010 @09:38AM (#33354156)

    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.

  • by ArsenneLupin ( 766289 ) on Tuesday August 24, 2010 @09:52AM (#33354388)

    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...

  • by arth1 ( 260657 ) on Tuesday August 24, 2010 @10:03AM (#33354550) Homepage Journal

    A simple fix would be for a programmer to have their app at initialization checksum any dll it uses.

    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.

  • by Anonymous Coward on Tuesday August 24, 2010 @10:06AM (#33354604)

    That doesn't work if the DLL is already loaded on behalf of the other application. You'll get that version, too.

  • by John Betonschaar ( 178617 ) on Tuesday August 24, 2010 @10:07AM (#33354620)

    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)

    by Anonymous Coward on Tuesday August 24, 2010 @10:11AM (#33354680)
    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.'
  • Re:Not quite (Score:3, Insightful)

    by L4t3r4lu5 ( 1216702 ) on Tuesday August 24, 2010 @10:36AM (#33355016)
    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.
  • Re:Not quite (Score:4, Insightful)

    by sp3d2orbit ( 81173 ) on Tuesday August 24, 2010 @10:36AM (#33355026)

    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.

"For a male and female to live continuously together is... biologically speaking, an extremely unnatural condition." -- Robert Briffault