Windows DLL Vulnerability: Microsoft Security Flaw

Computerworld - The appearance Monday of exploit code for the DLL loading issue that reportedly affects hundreds of Windows applications means hackers will probably start hammering on PCs shortly, security experts argued.

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

Storms was referring to the release earlier today of exploit code by HD Moore, the creator of the Metasploit open-source hacking toolkit.

Moore also issued an auditing tool that records vulnerable applications, information which can then be used to launch the exploit code that Moore crafted and added to Metasploit.

Together, the tool and exploit create an effective "point-and-shoot" attack, said Moore.

"With it in Metasploit, people will definitely be looking at these [vulnerabilities]," said Wolfgang Kandek, CTO at Qualys. "They gain a lot of visibility once in Metasploit, and I'd expect to see some kind of public exploit in the next couple of weeks."

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.

Many Windows programs can be exploited simply by tricking users into visiting malicious Web sites or opening malformed documents because of the way the software loads code libraries -- dubbed "dynamic-link library," or ".dll" in Windows -- as well as executable ".exe" and ".com" files. If hackers can plant disguised malware in one of the directories an application searches when it looks for those files, they can hijack the PC.

Oh, and note the order things are checked for the DLL (a SPECIFIC NAMED DLL that is called from the application); if you find that DLL in the application directory (you haven’t deleted it, have you?) or the system directory (the other place things are typically installed), then you STOP SEARCHING, you never get even further IF for some reason the application changed the current working directory.

It depends upon the way you have set up your application. You can program more securely or less securely depending upon the the dynamic-link library search order that you are using.

This is from Microsoft's security advisory:

This issue is caused by specific insecure programming practices that allow so-called "binary planting" or "DLL preloading attacks". These practices could allow an attacker to remotely execute arbitrary code in the context of the user running the vulnerable application when the user opens a file from an untrusted location...Microsoft is also actively investigating which of its own applications may be affected.

Not even Microsoft know which of its applications may be affected. You will find the advisory here:
http://www.microsoft.com/technet/security/advisory/2269637.mspx.

Do you know what the current directory is? It’s NOT the data directory, you might want to check that out. Write an app, and do a GetCurrentDirectory() call and tell me what you get returned. HINT: it’s not the default data directory...

That depends on how the applications has been written. Here is the way that Microsoft explains the problem in its security advisory:

Some Application Programming Interfaces (API), such as SearchPath, use a search order that is intended for documents and not application libraries. Applications that use this API may try to load the library from the Current Working Directory (CWD), which may be controlled by an attacker. Other APIs may also lead to similar behavior.

The current working directory may indeed be the directory with your data files. Again, it depends on the way the application has been written.

Like I said, write a quick Windows app (you can download Visual Studio for free), make a call to GetCurrentDirectory( ) and find out what the current directory is. You can report back here.

In fact, if you like, you can download a little Win app I just wrote that does this very thing. You can download it here if you like. It's a dialog box app, simply reports the current working directory. Interesting, no?

And then realize that the pre-existing DLL - the one that shipped with the app would need to no longer exist to look beyond what is reported. So somehow you would have had to first DELETE or OVERWRITE the existing DLL.

This exploit has been known for 4+ years (see my link above), and it's a non-issue exploit because it is so far beyond fantastic, AND requires the user to explicitly damage an app install OR arbitrarily change directories, as to be essentially a non-issue.

Again, this is nothing more than your more run-of-the-mill trojan as I originally stated up near the beginning, and as you know - if you can get the user to download your code and execute it (or, in this case, save it to a particular location overwriting existing files, OR deleting an existing file) then all bets are off. The OS cannot save you, no matter what you want.

This is pretty much FUD...

You missed this part from Microsoft's security advisory:

This issue is caused by specific insecure programming practices that allow so-called "binary planting" or "DLL preloading attacks". These practices could allow an attacker to remotely execute arbitrary code in the context of the user running the vulnerable application when the user opens a file from an untrusted location.

Also, this is what Moore had to day (the man who found the "old" new vulnerability in 40 applications:

"The vector is slightly different between applications, but the end result is an attacker-supplied .dll being loaded after the user opens a 'safe' file type from a network share [either on the local network or the Internet]," Moore said in an e-mail reply to questions. "It is possible to force a user to open a file from the share, either through their Web browser or by abusing other applications, for example, Office documents with embedded content."

Apparently you've encountered a standard where DLLs are not in the application directory or the system path?

Aside from that and shared DLL folders, normally no. And that's the problem. Why does Windows, in addition to the above and any application-specified folders, look in the current directory and every directory in PATH if those are not normal locations for DLLs? Seems kind of stupid, but that's what this exploit leverages since Windows will load a DLL from wherever it's found on the computer, not just application and system folders.

If that's the standard of your shop, I'd suggest changing your practices

Remember me talking about developers needing to be slapped?

Do you know what the current directory is?

For a shortcut-launched program it's whatever's in the "Start In" field of the properties. Otherwise it's an option in the command line used to start an application, in application executable's folder, other application specified or system-saved from last time. I may have missed one or two more ways it can be specified.

And SafeDllSearchMode is disabled by default. It can screw up programs that expect to find DLLs in the current directory.

Like I said, write a quick Windows app (you can download Visual Studio for free), make a call to GetCurrentDirectory( ) and find out what the current directory is.

It can be whatever the app makes it. You didn't do a SetCurrentDirectory first, did you? Even better, you didn't do a SetDllDirectory, did you?

You can download it here if you like. It's a dialog box app, simply reports the current working directory. Interesting, no?

Using a shortcut to launch it, the usual method for applications, I just made it report "c:\" as the current directory when I launched it from a different location. What, you didn't explicitly set your current directory so it couldn't be screwed with? Tsk, tsk.

Instead of the whole compile and download thing, two lines of VBScript could have done it:

set wshell = createobject("wscript.shell")
wscript.echo wshell.currentdirectory

Of course the shortcut properties trick works on this too.

This exploit has been known for 4+ years (see my link above), and it's a non-issue exploit because it is so far beyond fantastic.

It's not for every program, but with the vast number of programs out there and Windows' own behavior, the stars can align to create this problem. Between all the ways that paths are included in the DLL search, there have apparently been many alignments.

The absolute overall fix from Microsoft is simple, but Microsoft may not have the balls to piss off users when their programs stop working. Microsoft certainly didn't before when hacks were programmed into Windows to fix individual buggy programs.

You need to read the research PDF by Kwon. According to their criteria they found over 1,700 instances of unsafe DLL loading. All of this is basically showcasing the fact that Windows isn't out of DLL Hell quite yet. This is just another symptom.

This problem has been around for 4 years at the very least, and as you say above, there's no way to protect a computer from infection if the user doesn't know what they're doing.

Well, it is pretty well known in Win OS miniaturizing circles that .dlls placed on the desktop are found by the system - I have been testing that way going back to Win95(950b)... The desktop as an infection vector is a pretty glaring and obvious place...

Placing .dlls in an application's folder goes back just as far. Older programs often cannot use newer dll versions, as critical functions have been discontinued over time. Dropping the older dll into the app's folder gives it priority when that particular app is fired.

Viruses and trojans have long been "pathing" the temp directory and running from there - That it would be an out-of-place dll is really no different than an out-of-place svchost.exe... Any moron with a decent startup editor can find this stuff.

This is much ado about nothing. AVs have been catching infected dlls as long as I can remember.

This is much ado about nothing. AVs have been catching infected dlls as long as I can remember.

The guy who runs a little computer shop in my neighborhood makes a nice living cleaning up people's systems who have been invected with viruses, malware, trojans, etc. on Windows systems. At least this much ado about nothing keeps a man employed.

Any moron with a decent startup editor can find this stuff.

The next time I go to my parents' house I will tell them what morons they are for not knowing how to use a startup editor. In the meantime it's up to me to be make sure their AV subscription is paid up, installed properly, turned on, updating, and working. But the school teacher down the block was not so lucky a few weeks ago. She had to have her OS completely reinstalled. Nor was the architect I know who lost all his local files. But the next time I see these people I will tell them what morons they are for being infected and not knowing how to use a startup editor.

There you go. This is an ancient vector, that requires a VERY non-standard situation (an installed DLL being deleted, or the path being manually edited by the user, or saving a file to a new location and overwriting and existing file). Yes it's a hole, but it's - as you say - much ado about nothing.

In a nutshell, you are right- But it isn't a non-standard situation at all - any batch queen can shove a directory to the front of the path... and anyone who understands .inf files can create a shortcut with a different "Start in," or working directory... And do so surreptitiously and quite automatically. IOW, this is all simple and ancient. SOSDD.

The truth of it is that ANY program (with the exception of a true, kernel level root kit) can be sniffed to discover it's dependencies and resources- And that precise action is performed by every AV, regardless of where the dependency or resource lies. The act of calling up a resource causes it to be scanned as a matter of course - no matter where it's located.

So with the exception of removing path statements and reg entries, the main threat is dispatched as a matter of course.

This is an ancient vector

You make it sound that Microsoft not cleaning this up for years is a positive thing.

that requires a VERY non-standard situation

The problem being that 1) Over a thousand such non-standard situations apparently exist and 2) the operating system allows such non-standard situations. Microsoft could disallow those situations, fixing the problem at their end, but that would break those apps, and for some reason Microsoft feels the need to take on responsibility for developer error.

an installed DLL being deleted, or the path being manually edited by the user, or saving a file to a new location and overwriting and existing file

Or a bunch of other things. I just made an HTML page that scripts the current directory displays it. Loaded into a fresh-run IE, it shows my desktop directory. That means my desktop, a common download location, is in line to load DLLs under IE.

So with the exception of removing path statements and reg entries, the main threat is dispatched as a matter of course.

With the exception of removing path statements and reg entries? That sounds like a rather large exception.

And that precise action is performed by every AV, regardless of where the dependency or resource lies.

And if your AV is not running or updating or even installed, what then?

The guy who runs a little computer shop in my neighborhood makes a nice living cleaning up people's systems who have been invected with viruses, malware, trojans, etc. on Windows systems.

Then he is screwing people. I have over 300 people/businesses in my stable, and I am starving- If it weren't for new clients coming in with infections, I wouldn't have enough virus business to worry about. My regulars don't get infected... Because I teach them to avoid being morons.

If they have a good AV with a good Anti-Spyware program, they are not going to be affected by this so-called "exploit"... It isn't a new thing, and any good AV already protects against this. In the mean-time... Why don't you learn how to run a startup editor, and quit your whining?

But the school teacher down the block was not so lucky a few weeks ago. She had to have her OS completely reinstalled.

I cry bullcrap. I haven't reinstalled but a handful of systems due to virus this whole year. There is hardly ever a reason to - Even a full-fledged root-kit can be removed (though sometimes it isn't worth the time).

Nor was the architect I know who lost all his local files.

I cry bullcrap sommore. Tell your architect friend he needs a better tech.

But the next time I see these people I will tell them what morons they are for being infected and not knowing how to use a startup editor.

Look. It's a computer, not a can-opener. Just like with your car, if you, personally, have no understanding about how it works, you WILL pay through the nose. It's really that simple. Buyer beware. In the mean time, getting your undies all in a bunch every time some moron spews a bunch of FUD does neither you, nor your friends any good. LEARN. Knowledge is power.

With the exception of removing path statements and reg entries? That sounds like a rather large exception.

Not really. And by the time a virus is well known, the AV fixes these things as a matter of course... But it is reasonably simple to fix without an AV.

And if your AV is not running or updating or even installed, what then?

Sounds like an ID-10T problem to me.

You make it sound that Microsoft not cleaning this up for years is a positive thing.

It isn't "cleaned up" because it doesn't need to be, nor can it be. It is the nature of computing.

2) the operating system allows such non-standard situations. Microsoft could disallow those situations, fixing the problem at their end, but that would break those apps, and for some reason Microsoft feels the need to take on responsibility for developer error.

NONSENSE. There isn't an OS on the planet that has this "cleaned up"... Because it is the nature of the beast. Every OS operates by pathed directories, and every OS is susceptible to it's own scripting being turned against it. In fact, Apple and Linux are more susceptible, as their scripting is vastly more powerful.

I just made an HTML page that scripts the current directory displays it. Loaded into a fresh-run IE, it shows my desktop directory. That means my desktop, a common download location, is in line to load DLLs under IE.

your desktop is almost always in the path because it is a folder - and since you are sitting in it (...%user%\desktop\) while you are operating from the desktop, it is the current working directory. *shakes head*

But it is reasonably simple to fix without an AV.

For you it would be simple to fix. The average person would not have a clue how to do this.

I used to work for a small company in the IS department. Among other things I had to manage 50 Windows desktops. The company was too cheap to buy AV software, so when someone got infected, I had to clean up their machines. Sometimes I had to edit the registry to cleanup the mess. What a royal pain. I found that it was easier just to reinstall the OS and data files than track down all the changes a virus had done.

Sounds like an ID-10T problem to me.

Calling people idiots does not solve anything.

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.