Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Windows DLL Vulnerability Exploit In the Wild

Soulskill posted more than 4 years ago | from the is-it-tuesday-again-already dept.

Bug 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].'"

Sorry! There are no comments related to the filter you selected.

Application developers fault (2, Informative)

odies (1869886) | more than 4 years ago | (#33353354)

This is actually faulty programming in applications [computerworld.com] , 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 [microsoft.com] 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.

And Also Four of Microsoft's Applications (5, Informative)

eldavojohn (898314) | more than 4 years ago | (#33353380)

There are no reports of any Microsoft or default Windows applications containing the bug

Really? That's odd, from the original blog posting [rapid7.com] :

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.

Re:And Also Four of Microsoft's Applications (4, Insightful)

Xacid (560407) | more than 4 years ago | (#33353814)

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.

Re:And Also Four of Microsoft's Applications (0)

Anonymous Coward | more than 4 years ago | (#33354228)

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.

So it's okay to exonerate Microsoft and absolve them of all blame.

Except they're just as guilty as the devilish third party applications.

Re:And Also Four of Microsoft's Applications (1)

Xacid (560407) | more than 4 years ago | (#33354626)

As much as it's okay to burn them at the stake for this as well. As mentioned earlier - this isn't a problem with the OS, it's a problem with how people are programming. Microsoft is just as culpable for it as everyone else - and from the sounds of it they're already working to fix it. If that doesn't satisfy you enough then go buy a Mac, get off slashdot, and learn to program perfect code yourself.

Re:And Also Four of Microsoft's Applications (1)

Zalbik (308903) | more than 4 years ago | (#33355344)

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.

Yes, but the original claim was:

There are no reports of any Microsoft or default Windows applications containing the bug

This claim is obviously false as there are Microsoft applications containing the bug. What we can say is that issue is not the fault of the Microsoft OS developers.

Four or Forty? (0)

Anonymous Coward | more than 4 years ago | (#33355980)

The ComputerWorld link [computerworld.com] reads 40 Microsoft apps contain the flaw. The only exposed [computerworld.com] Microsoft app is the shell, explorer.exe.

Re:Application developers fault (-1, Troll)

Anonymous Coward | more than 4 years ago | (#33353468)

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.

Jesus H. Christ, yet another sopssa [slashdot.org] shill account.

Re:Application developers fault (1, Interesting)

g0bshiTe (596213) | more than 4 years ago | (#33353482)

Many Windows applications don't call code libraries -- dubbed "dynamic-link library," or "DLL" -- using the full pathname, but instead use only the filename, giving hackers wiggle room. Criminals can exploit that by tricking the application into loading a malicious file with the same name as the required DLL. The result: Hackers can hijack the PC and plant malware on the machine.

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.

Re:Application developers fault (5, Insightful)

Zocalo (252965) | more than 4 years ago | (#33353548)

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:Application developers fault (1)

denis-The-menace (471988) | more than 4 years ago | (#33354230)

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. In "MSI packaging Land" this is called "Application Isolation".

Application Developers are rarely good packagers.

Re:Application developers fault (1, Insightful)

Anonymous Coward | more than 4 years ago | (#33354604)

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 (3, Insightful)

John Betonschaar (178617) | more than 4 years ago | (#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

Re:Application developers fault (1)

Zocalo (252965) | more than 4 years ago | (#33354728)

That's why I specified "in a shared location". :)

I don't actually think there is an easy, one-size-fits-all solution to this problem without a radical shakeup of how Windows handles DLLs. If you insist on applications each installing their own versions of each DLL then you end up with a potential nightmare when there is a flaw found in some versions of a given DLL like with atl.dll a while back. At least you'd know which apps are vulnerable, but that's not going to be much help when one of those is essential to your business and the app breaks if you update the DLL manually.

Re:Application developers fault (1)

Ralish (775196) | more than 4 years ago | (#33354694)

OK, there's a fix for that, but only if you can call the awful kludge that is WinSxS a "fix".

I always thought that WinSxS was quite an elegant fix to a difficult problem. Put it this way, I still have nightmares about DLL Hell from the bad old days, but have yet to encounter a problem due to WinSxS. The closest I've come is one or two applications making assumptions about dependencies (i.e. not bundling the required installers and not failing gracefully). Have you had issues with WinSxS?

Re:Application developers fault (1)

0123456 (636235) | more than 4 years ago | (#33355306)

I always thought that WinSxS was quite an elegant fix to a difficult problem.

Weird, I always thought it was a horrible kludge.

Put it this way, I still have nightmares about DLL Hell from the bad old days, but have yet to encounter a problem due to WinSxS.

Either you're lucky or I'm unlucky, because my old XP PC has a serious case of 'SxS Hell' that I've been totally unable to fix. It's a long time since I've booted it, but I remember spending hours poking around in the SxS directories trying to figure out what the hell Windows had screwed up there to prevent some applications from running. It also refuses to install the service pack for the .Net Framework, apparently for the same reason.

I'm so glad I run Linux for anything other than Windows-only games and video editing these days.

Re:Application developers fault (1)

g0bshiTe (596213) | more than 4 years ago | (#33354704)

I never even considered updated DLL's.

Re:Application developers fault (1)

master_p (608214) | more than 4 years ago | (#33355396)

And all this trouble because Microsoft denied doing the sane thing, i.e. name its DLLs with a version number (as well as the DLL name).

Re:Application developers fault (0)

Anonymous Coward | more than 4 years ago | (#33356014)

You can always sign the assemblies.

Re:Application developers fault (1)

clone53421 (1310749) | more than 4 years ago | (#33353646)

A simple fix would be for a programmer to keep data separate from executable code.

FTFY.

Re:Application developers fault (5, Insightful)

pelrun (25021) | more than 4 years ago | (#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*.

Re:Application developers fault (2, Insightful)

arth1 (260657) | more than 4 years ago | (#33354550)

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.

Re:Application developers fault (2, Interesting)

UnknowingFool (672806) | more than 4 years ago | (#33353540)

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.

Re:Application developers fault (1, Insightful)

Anonymous Coward | more than 4 years ago | (#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.

Re:Application developers fault (0)

Anonymous Coward | more than 4 years ago | (#33354036)

... shitty programs like ITunes on windows ...

Its funny, out of the over 40 programs known to be affected, you call out by name the one that is known to have been patched four months ago. [computerworld.com]

Re:Application developers fault (1)

wjousts (1529427) | more than 4 years ago | (#33354184)

Doesn't change the fact that it runs as a service for no sensible reason at all.

Re:Application developers fault (1)

UnknowingFool (672806) | more than 4 years ago | (#33354542)

I think the reason iTunes runs as a service has to do with automatic syncing. When you plug in your iPhone/iPod/iPad, if you have the service running, iTunes knows to load and then automatic sync. Otherwise you'd have to load iTunes and sync. If that is not your wishes, just turn it off.

Re:Application developers fault (0)

Anonymous Coward | more than 4 years ago | (#33354208)

More than likely he didn't even look to see if ITunes was affected. He called ITunes out for its service infestation policies, not for any faults in the way it loads DLLs.

Re:Application developers fault (0)

Anonymous Coward | more than 4 years ago | (#33354686)

Yeah cause no other Windows syncing tool clutters my taskbar and services.

Re:Application developers fault (0)

Anonymous Coward | more than 4 years ago | (#33355928)

Yeah cause no other Windows syncing tool clutters my taskbar and services

I don't get your point... it appears that the logic you're attempting to employ is either, because there are OTHER shitty programs out there, iTunes itself isn't shitty, OR it's okay for iTunes to be shitty because there's other shit out there too...

I don't see how either one discredits or invalidates the original assertion; i.e. iTunes is shitty...

-AC

Re:Application developers fault (1)

0ld_d0g (923931) | more than 4 years ago | (#33354530)

Its shitty because it installs itself as a service (i.e. admin privs) to do some crap it doesn't need to. (according to the OP).

Re:Application developers fault (-1)

Anonymous Coward | more than 4 years ago | (#33353550)

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.

Such as those who think that C and C++ are the same programming language?

Re:Application developers fault (2, Interesting)

dbIII (701233) | more than 4 years ago | (#33353744)

To protect from stupid developers you would probably need something like selinux for Windows

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.

Re:Application developers fault (1)

0123456 (636235) | more than 4 years ago | (#33355488)

A list of what is allowed provides far better protection than an ever changing list of what is not allowed.

The problem is that vast numbers of Windows programs rely on being able to do things that shouldn't be allowed, and people only buy Windows because it will run all their old Windows programs. So Microsoft are screwed either way.

Maybe it could be done in 20 years when most people have replaced most software with new versions, or by virtualising all old applications, but it would not be an easy job.

Re:Application developers fault (5, Insightful)

MojoRilla (591502) | more than 4 years ago | (#33353836)

Microsoft created a liberal dynamic library search path that allows [microsoft.com] (or even encourages) applications to not fully specify DLL locations. Now, after the fact, they publish this security [microsoft.com] 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:Application developers fault (1)

ILuvSP (625676) | more than 4 years ago | (#33353938)

Exactly! Saying that this is the developer's fault is a bit of a cop-out for Microsoft.

Re:Application developers fault (5, Interesting)

mdwh2 (535323) | more than 4 years ago | (#33354018)

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's OWN fault !! (5, Insightful)

Anne Honime (828246) | more than 4 years ago | (#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.

Re:Application developers fault (1)

mcgrew (92797) | more than 4 years ago | (#33354430)

Generally, when code reaches this level of complexity and brittleness, it is often the best course to start all over.

Or in the immortal words of Montgomery Scott (Star Trek III), "The more you overengineer the plumbing, the easier it is to stop up the drain."

Re:Application developers fault (1)

CKW (409971) | more than 4 years ago | (#33354608)

> The bottom line is that Windows was never designed to be secure

Oooh, that makes me wonder. Can Linux/Solaris/Unix be attacked *simply* using the PATH environment variable? Forget limiting the attack to shared objects, anything that is loaded or exec'd by any other binary/scripts.

The complicated thing is many applications build their own PATHs, and you're looking for a directory on that path that is writable to whatever user you are, one that you can put a file that doesn't yet appear that high up on the PATH.

Which suddenly makes it brilliantly clear that perhaps this isn't an OS problem. Not unless you're going to ALSO blame all the Unix/Linux authors 10-40 years ago for "(not) consider(ing) security at all when (using PATHs)", and for somehow magically making sure applications and installers don't accidentially leave directories writable by other users.

Re:Application developers fault (1)

CKW (409971) | more than 4 years ago | (#33354650)

I wonder how long it would take with dtrace/truss/strace/etc to build a similar tool on Unix/Linux.

(( Sorry for the quick re-reply (Slashdot, isn't it time for an edit button?) ))

Re:Application developers fault (1)

Anne Honime (828246) | more than 4 years ago | (#33354892)

You'd need to already own the computer to pull something like that, which pretty much defeats the purpose. But, yes, it's been used in the past, along with other techniques. The intrinsic problem here is not to have a search path for execs and libs, but to provide hardcoded at system level a default path with $PWD included, instead of a path exclusively containing system directories under admin control.

Re:Application developers fault (1)

Ralish (775196) | more than 4 years ago | (#33355004)

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.

So basically, your suggestion is to design an OS that ensures that it is secure by taking away API calls that could be misused in a way that compromises security? By your own admission, it is a documented specification, and it is behaving exactly as it is intended to do so. It isn't a "bug" in the API, it's misuse by various developers. However, Microsoft is at fault for how developers (its own or 3rd-party) misuse an API call that is fully documented and behaving exactly as intended? This makes absolute, perfect sense.

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.

Yes, they are blaming applications that have incorrectly used the documented specification. And, they have provided the capability to control remote loading of DLLs through a patch that can be targetted at individual applications or the entire OS. What more can reasonably be done?

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.

And this is factually wrong. Windows NT (as opposed to Windows) was designed from Day 1 to be secure. You can argue whether they succeeded in developing a secure OS, and that might be a far more interesting debate, but to argue that it was never designed to be secure is incorrect. This is a fact of historical record. I'd argue that earlier versions of Windows NT were significantly flawed from a security perspective while modern versions (Vista and newer) are significantly improved, but that's another debate.

Essentially, your entire argument is that it is Microsoft's fault for providing a documented API that can be misused. I'll grant the defaults could have been chosen better, but competent programmers need to be aware of these issues. I'm mildly surprised it's getting the coverage it is, as this isn't some brand new attack; this issue has been known about for some time and not gotten a lot of coverage because it simply isn't that big a deal and is not a flaw in the underlying OS. For example, this blog post from early 2008 covers the issue (and was linked in some more recent blog posts): DLL Preloading Attacks [msdn.com]

Re:Application developers fault (1)

master_p (608214) | more than 4 years ago | (#33355466)

There is a way out for Microsoft: they can "virtualize" the O/S so as that apps think it's like Windows 95, where they can own all files, but in reality the apps would only do damage to their own version of the files.

Re:Application developers fault (1)

interval1066 (668936) | more than 4 years ago | (#33355618)

What do you expect from an OS that has a default color scheme that's very much like the livery of a clown car?

Re:Application developers fault (1, Interesting)

Anonymous Coward | more than 4 years ago | (#33354102)

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.

Re:Application developers fault (4, Informative)

NiteShaed (315799) | more than 4 years ago | (#33355146)

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.

Ummmmmm; "According to Moore, at least one Microsoft executable -- "explorer.exe," the Windows shell -- includes the flaw. [computerworld.com] "
I'm pretty sure your Windows machine has explorer.exe loaded by default.

Re:Application developers fault (1)

ThePhilips (752041) | more than 4 years ago | (#33355538)

Because application developers, not Windows, are to blame

Because clean design of many Windows APIs inspires secure coding practices.

And MS has totally nothing to do with the fact that some of the APIs are so developer-friendly.

[/sarcasm]

Re:Application developers fault (1)

xmorg (718633) | more than 4 years ago | (#33355908)

How is this not flamebait?!?! we obviously have a windows fanboy drooling over C#... IE yet another oop language that does garbage collection. That is so 90's bub.

Not quite (0)

RenHoek (101570) | more than 4 years ago | (#33353372)

>'The hard part has already been done for [script kiddies].'

Here, I fixed it for ya. No self-respecting coder would use a library like that.

Re:Not quite (5, Insightful)

Lazareth (1756336) | more than 4 years ago | (#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.

Re:Not quite (1)

L4t3r4lu5 (1216702) | more than 4 years ago | (#33353694)

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.

Re:Not quite (1)

FuckingNickName (1362625) | more than 4 years ago | (#33353964)

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

Re:Not quite (2, Insightful)

L4t3r4lu5 (1216702) | more than 4 years ago | (#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 (1)

Crudely_Indecent (739699) | more than 4 years ago | (#33353824)

I'd like to introduce you to Dan Bernstein [cr.yp.to] , 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.

Re:Not quite (0)

Anonymous Coward | more than 4 years ago | (#33354074)

'd like to introduce you to Dan Bernstein [cr.yp.to], creator of QMail and DJBDNS.

Certainly, he could've accepted that BIND, Sendmail and Postfix were functional, but what fun would that be?

Well, when your God Dan creates a C library, compiler, POSIX kernel, a new HDL, and then the design for the hardware in that new HDL to run your oh-so-perfect DNS server from the last century, I'll *start* to see your point.

Re:Not quite (1)

olderchurch (242469) | more than 4 years ago | (#33354698)

In our polytheism world we can have multiple gods [theos.com] , so we have a secure OS [openbsd.org] that can run QMail and DJBDNS

Re:Not quite (2, Insightful)

Ecuador (740021) | more than 4 years ago | (#33354066)

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.

Re:Not quite (1)

pclminion (145572) | more than 4 years ago | (#33355398)

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.

Re:Not quite (0)

Anonymous Coward | more than 4 years ago | (#33354098)

Yes, I for one have already four or five better wheel designs that you, especially my gradient one.

Re:Not quite (3, Insightful)

jeffasselin (566598) | more than 4 years ago | (#33353614)

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:Not quite (3, Insightful)

sp3d2orbit (81173) | more than 4 years ago | (#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.

Re:Not quite (0)

Anonymous Coward | more than 4 years ago | (#33353930)

>self-respecting coder
>coder
>ya

Seriously? What are we here, 13?

Reinventing the wheel over and over again gets boring by the time you actually have a job and life to lead.
Every (intelligent) programmer uses libraries for things that are useless to reinvent every single time.
Whether it is using a library method in the language itself or just copy-pasting snippets from a text file, both are useful.

I suppose you probably also wrote that browser and OS you're using as well?
After all, no self-respecting elite haxxor would use an OS and software made by someone else, right?

Re:Not quite (1)

TheLink (130905) | more than 4 years ago | (#33354990)

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

Helps Microsoft, helps malware-biz (1)

h00manist (800926) | more than 4 years ago | (#33353576)

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.

Re:Helps Microsoft, helps malware-biz (1)

mcgrew (92797) | more than 4 years ago | (#33353848)

TFS says there's a detection tool; run the tool and uninstall any apps that have the vuln and you're safe(er).

Requires user action (1)

munky99999 (781012) | more than 4 years ago | (#33353608)

The exploit requires user action. So the exploit isnt going to be as bad as it could have been.

Re:Requires user action (1)

0123456 (636235) | more than 4 years ago | (#33355516)

The exploit requires user action. So the exploit isnt going to be as bad as it could have been.

Until some virus starts writing compromised .DLL files to every network share in the company.

Huh? (3, Interesting)

FranTaylor (164577) | more than 4 years ago | (#33353768)

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

wait, open a remote file through SMB ? (1, Informative)

Anonymous Coward | more than 4 years ago | (#33353858)

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

Re:wait, open a remote file through SMB ? (1)

nomaddamon (1783058) | more than 4 years ago | (#33354044)

Consider opening a media file, with your trusted program from SMB. If the attacker has planted a malicious .dll file in the same SMB share and your "trusted" media playing application is vulnerable then you have just compromised yourself.

Re:wait, open a remote file through SMB ? (2, Interesting)

ArsenneLupin (766289) | more than 4 years ago | (#33354206)

Even worse, consider visting a web page with <img src="file://maliciousSmbServer/share/test.jpg"> somewhere in it...

Re:wait, open a remote file through SMB ? (1)

gravyface (592485) | more than 4 years ago | (#33354244)

Egress filtering at the perimeter FTW. It's amazing what people let *out* of their networks...

Re:wait, open a remote file through SMB ? (2, Insightful)

ArsenneLupin (766289) | more than 4 years ago | (#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...

Re:wait, open a remote file through SMB ? (1)

clone53421 (1310749) | more than 4 years ago | (#33354284)

That doesn’t use the OS shell extension handler.

Re:wait, open a remote file through SMB ? (1)

clone53421 (1310749) | more than 4 years ago | (#33354328)

* Of course, <iframe src="file://maliciousSmbServer/share/bad.pdf"></iframe> very well might... but the browser shouldn’t let it do that. (Just tested in Firefox. Security error.)

Re:wait, open a remote file through SMB ? (0)

Anonymous Coward | more than 4 years ago | (#33354836)

This makes no sense. Why is Windows changing the current directory path when navigation occurs in an opened file dialog? It should have zero influence on the program state.

Re:wait, open a remote file through SMB ? (1)

arth1 (260657) | more than 4 years ago | (#33355012)

Contrary to what you seem to think, it's not only exploitable over SMB.
A user downloading and extracting an archive with non-executable files (images, mp3s, videos, whatever) are just as vulnerable if there's a DLL in the archive too.

It's also likely that other delivery mechanisms exist too -- consider an e-mail client that saves all embedded images and other files to a temporary folder, for example.

Their security recommendation is hardly a solution (2, Interesting)

postmortem (906676) | more than 4 years ago | (#33353914)

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

Re:Their security recommendation is hardly a solut (1)

clone53421 (1310749) | more than 4 years ago | (#33354120)

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.

Re:Their security recommendation is hardly a solut (1)

mdwh2 (535323) | more than 4 years ago | (#33354690)

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)?

Re:Their security recommendation is hardly a solut (3, Informative)

0ld_d0g (923931) | more than 4 years ago | (#33354480)

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.

The problem is not leap seconds... (-1, Offtopic)

AB3A (192265) | more than 4 years ago | (#33353976)

...the problem is in fact oversimplification of horology. We do not have a reasonable, standard practice for dealing with leap seconds. I've never heard of an OS that allows for 61 (or 59) seconds in a minute. Though it has never happened, leap seconds can theoretically go the other way.

To make matters worse, this concept needs to extend from the OS in to an application. Almost nobody has made the effort to handle this well. It is a relatively rare occurrence these days.

The ultimate question is why we're measuring time based upon the earth's rotation in the first place. Yes, our standards did come from the concept of dividing an astronomical day of the year in to smaller pieces, but our definition of those time units has not used the earth as a reference since 1967. Perhaps we have reached a point where the time of day concept is a bit more arbitrary?

We are able to find stars and know our longitude with very high accuracy without using leap seconds (that's how GPS does it). Is there still a reason why we should keep adjusting our concept of time according to what the earth does?

Re:The problem is not leap seconds... (1)

xSander (1227106) | more than 4 years ago | (#33354116)

I think the post above was intended for this article [slashdot.org] ...

I can see this being useful for propagation... (1)

gravyface (592485) | more than 4 years ago | (#33354008)

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.

Three letters (0)

Anonymous Coward | more than 4 years ago | (#33354402)

DEP

Re:Three letters (1)

Galestar (1473827) | more than 4 years ago | (#33354548)

2 letters: NO
as in NO, that doesn't do anything to fix this.

Re:Three letters (0)

Anonymous Coward | more than 4 years ago | (#33355250)

Since when doesn't DEP fix buffer overflow exploits?

Re:Three letters (2)

Galestar (1473827) | more than 4 years ago | (#33355886)

It does, but this has nothing to do with buffer overflows. Please RTFA.

Re:Three letters (2)

valeo.de (1853046) | more than 4 years ago | (#33356060)

Since when is does this exploit involve overflowing buffers?

I'm sorry what's the problem? (2, Interesting)

js3 (319268) | more than 4 years ago | (#33354486)

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.

Re:I'm sorry what's the problem? (1)

ledow (319597) | more than 4 years ago | (#33354634)

You map a network drive on your LAN, you execute a program on it that requires a DLL. That DLL can't be found unless Windows looks on the remote drive too, and chances are that if a program is bundled with a DLL, that DLL is actually a better match for the program than anything lurking in the Windows folder or other paths. So there is a use-case here - I'm pretty sure there's at least one school system I've worked on that would just break in a second if you couldn't load DLL's from a remote network location, and for not much reason ("The installation files are all there, I can see them, they are in the read-only mapped public drive we've always used for software distribution, etc." - and at least one school administration package I know runs from a shared Windows drive on the server thus requiring zero installation on the client)

I agree that the things being blown out of all proportion - if someone can place a file on your drive in any way, shape or form, it's game over anyway, Windows File Protection or not. More importantly, why the HELL haven't we fixed this DLL mess yet to only load DLL's from the application folder and then let people hard-link to a shared copy if they really want to share libraries between applications?

the problem (1, Insightful)

Anonymous Coward | more than 4 years ago | (#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 [metasploit.com] ". This is exploitable in most cases and affects at least one Microsoft product.'

Re:I'm sorry what's the problem? (4, Informative)

arth1 (260657) | more than 4 years ago | (#33354880)

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

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.

Just wow... (0)

Anonymous Coward | more than 4 years ago | (#33354968)

Apparently anything can be passed as a serious exploit today. This is the way LoadLibrary() has been worked ever since it's implementation, the OS will first query the target path (this doesn't need to be the path the application resides in, this can be set in the shortcut) and go all the way to the system folders --- in fact M$ mentions that this can be used to make applications load arbitary libraries on the very page where LoadLibrary() is documented on MSDN. Beside all this however, this is a rather moot exploit, if someone can place files in arbitary directories on your system, you're already compromized, and they don't need to do this to execute whatever code they wish to execute on the system, the exploit placing the files would usually involve RCE anyway (social engineering excluded, but if you can get people to put random files in locations for you, why not ask them to "run this harmless installer" right away?).

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.

Re:Just wow... (1)

0123456 (636235) | more than 4 years ago | (#33355564)

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.

How this works (5, Informative)

Elbows (208758) | more than 4 years ago | (#33355212)

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 [microsoft.com] ). It's even searched before $PATH!

Now the exploit goes like this:
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 .\bar.dll and load it into the unsuspecting foo.exe.
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).

Re:How this works (1)

master_p (608214) | more than 4 years ago | (#33355512)

Thank you, please mod parent up.

Re:How this works (1)

0123456 (636235) | more than 4 years ago | (#33355588)

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?

I've used a number of programs which would fail to run if you didn't start them from their install directory; I don't know whether they're looking for DLLs or data files, but I can be pretty sure that at least some programmers have relied on this behaviour without even realising... 'yeah, but we always run from our install directory, right?'

Re:How this works (2, Interesting)

cdrguru (88047) | more than 4 years ago | (#33356280)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?