Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

typodupeerror
• #### Re: (Score:2)

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, p

• #### Re: (Score:2)

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: (Score:2)

That's actually by and large what Vista and 7 do when an application without a manifest that declares Vista+ support tries to write into some known system folder that's not writable (e.g. its own install folder under "Program Files"). It silently creates a copy (if file already exists globally) to a user-local, app-specific folder, and then redirects all file operations to that copy.

• #### Re: (Score:2)

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 (Score:5, Informative)

on Tuesday August 24, 2010 @10:42AM (#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: (Score:2)

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]

• #### Not quite (Score:1)

>'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 (Score:5, Insightful)

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.

• #### Re: (Score:2)

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 rubbis
• #### Re: (Score:2)

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

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: (Score:2)

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.

• #### Re: (Score:2)

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

• #### Re: (Score:2)

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 (Score:4, Insightful)

<cormacolinde@@@gmail...com> 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.

• #### Re:Not quite (Score:4, Insightful)

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.

• #### Re: (Score:2)

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.

• #### Re: (Score:2)

> 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 (Score:2)

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: (Score:2)

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 (Score:1)

The exploit requires user action. So the exploit isnt going to be as bad as it could have been.
• #### Re: (Score:2)

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? (Score:4, Interesting)

on Tuesday August 24, 2010 @09:02AM (#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.

• #### Here's a good test (Score:2)

Have you updated your kernel lately?
• #### Re: (Score:2)

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.

Fedora uses targeted policy by default, meaning there's confined and unconfined processes. Services/daemons are confined, User processes are unconfined (full permissions). Why? Because it's too freaking hard to set selinux contexts for user processes.

So your web browser, email, and bittorrent all are unaffected by selinux in most distros. I wouldn't recommend trying to setup contexts for them either, selinux is a nightmare. Apparmor at least you can get sane profiles for user applications.

• #### Their security recommendation is hardly a solution (Score:2, Interesting)

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

• #### Re: (Score:2)

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 b

• #### Re:Their security recommendation is hardly a solut (Score:4, Informative)

on Tuesday August 24, 2010 @09:57AM (#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.

• #### I can see this being useful for propagation... (Score:2)

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 fil
• #### I'm sorry what's the problem? (Score:3, Interesting)

on Tuesday August 24, 2010 @09:58AM (#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: (Score:2)

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 locati

• #### Re:I'm sorry what's the problem? (Score:5, Informative)

on Tuesday August 24, 2010 @10:25AM (#33354880) Homepage Journal

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.

• #### How this works (Score:5, Informative)

on Tuesday August 24, 2010 @10:47AM (#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: (Score:2)

Thank you, please mod parent up.

• #### Re: (Score:2)

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: (Score:3, Interesting)

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 o

• #### Re:How this works (Score:5, Informative)

on Tuesday August 24, 2010 @12:52PM (#33357242)

I just tried this out. When I launch a test program by double-clicking an associated file, the current directory (as returned by GetCurrentDirectory()) is set to the directory where the file was located. It ignores the location of the .exe, and it also ignores the "Start In" directory from the shortcut file (if the association was to a shortcut and not directly to an exe). This is on Win7 64-bit. So I think my evilsmbshare example from above would work as described. Of course it's possible that other Windows systems exhibit completely different behavior. :)

I agree that it's still hard to exploit, but not quite as hard as requiring access to the user's local filesystem.

• #### Re: (Score:2)

You can't associate files with shortcuts.
• #### Re: (Score:3, Informative)

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.

Actually it's write-protected in XP as well, as long as you don't use the FAT32 filesystem (so per-user file permissions actually exist) and as long as you're not running as admin (which nearly everyone did on their home PCs, but in organisations most people aren't). Vista basically changed the system from "local admin user = root" to "local admin user = sudoer".

• #### Re: (Score:2)

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.

Infected removable media would be the most likely vector. You plug in a USB flash drive or load a CDROM, browse to a file you want to open but don't notice the malicious DLL in the same directory, perhaps because it's hidden among hundreds of other files. We're used to being cautious about opening files on remo

• #### CWDIllegalInDllSearch (Score:2)

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 [microsoft.com]

MS fixed the other

• #### Re: (Score:3, Informative)

Or, correction, the good DLL would have to go into a folder that is in the PATH and not in any of the higher priority system folders. And you would have to register a file handler and a new type... since the directory of the EXE has first priority. Oh well.

The priority list goes:

1. The directory from which the application loaded
2. The system directory
3. The 16-bit system directory
4. The Windows directory
5. The current working directory (CWD)
6. The directories that are listed in the PATH environment variable

#### Related LinksTop of the: day, week, month.

MSDOS is not dead, it just smells that way. -- Henry Spencer

Working...