Posted on 08/24/2010 11:30:28 AM PDT by stripes1776
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.
...
(Excerpt) Read more at computerworld.com ...
Gives whole new meaning to the term: DLL Hell
It's sounds like you have a good security policy in place. But for others who don't have these restrictions in place, network administrators had better get busy.
There is no substitue for locking down the system folders
and maintaining access to them on a need to know basis.
Also it helps to run a good anti malware product, such as Kaspersky.
DLL Hell indeed. Windows is showing it's origins in stand-alone PCs that were not networked.
We used it in a middle school computer lab of about 40 Windows XP Pro PCs. The only calls we got after installing Deep Freeze were for hardware issues, not a single software or OS issue.
It also eliminated the need for antivirus, spyware, and malware programs.
http://www.faronics.com/en/Products/DeepFreeze/DeepFreezeCorporate.aspx
That is a good security policy, but most people are not system administrators. They are just people with computers who want to get some work done or surf the Internet. They won't know how to take the appropriate precautions.
The problem is with the Windows operating system. It allows code to be loaded and run in a rather promiscuous manner. But many legitimate programs rely on this promiscuous behavior to run. If Microsoft fixes the operating system, then a lot of program will break, including some programs from Microsoft.
This is going to take months to sort out.
So if I understand right, if the hacker can get the victim to download and save a copy of a file, then the computer can be compromised because that file might be loaded by another application already on the machine.
And this is different from a trojan - how?
Sorry, but the last line of defense is ALWAYS the user, and if you can get them to download and install your application, I don’t care WHAT kind of OS or virus protection they run - you own them.
How about a FIRST line of defense, say a bounty on hackers and writers/disseminators of malware?
Maybe just an open season... Bow, muzzle-loader, center-fire, shotgun, 2x4, crowbar???
Hey, sounds good to me as long as the tags are a reasonable price! :)
It has to do with the way that Windows loads .dll files. These files are executable code that the operating system loads dynamically and runs. There is a search order that the operating system uses to load these files. Every running application has the concept of a working directory or current directory (folder). Windows has a search order that it uses to find .dll files. By default the Windows operating system looks first in the same folder as the data file that has just been loaded. Then it looks in system folders. All the malicious hacker has to do is place a malicious .dll file in the same folder that you are downloading data from on a network, and the user's machine is now owned by the malicious hacker.
You can change the search order so that Windows looks in the system folders first and last in the working directory that the data came from. But if the name of the .dll is unique, windows will still find the file and load it. The user's system is still compromised.
And this is different from a trojan - how?
Sorry, but the last line of defense is ALWAYS the user, and if you can get them to download and install your application, I don’t care WHAT kind of OS or virus protection they run - you own them.
The user does not have to download and install an application. The application is already installed. The installed applications use .dll files. These .dll files will download automatically and run as part of the application. All the malicious hacker has to do is put a malicious .dll file in the same folder as the data you are looking at in an application. There is nothing to install.
The developer has to do some really stupid programming in order for this to work. Normally programs look for DLLs in their own program folder, a known shared DLL folder, or in the system32 folder. Normally browsers can be made to save on the desktop, my documents, or a download folder. The guy was able to exploit IE on this because IE actually looked in the desktop for DLL files. Huh? Some developer at Microsoft needs to be slapped, same for the developers of any of these other apps who did similiar things.
Well, that practice was not a problem back in the days when a Windows PC was a stand-alone machine without a connection to a network. But that is precisely the problem today when most computers are connected to a network. Even Microsoft still has applications that look in the current directory for .dll files. An operating system should not let a programmer do that in the first place.
Microsoft could patch Windows so that it will not look in the current directory. But then a lot of programs that depend on this feature will break. So, in the meantime, developers and vendors will have to rewrite their applications. At some point in the future, probably a few years from now, Microsoft will have to break backward compatibility.
This is a MAJOR flaw. I mean, it’s below OS level error, it’s systemic. Every program calls and looks for dll’s. And it seems their is no “special” place for them, you can look on your desktop!
WOW!
So much for the late great Windows 7....
Yes, this is a major security hole. It will keep network administrators very busy locking down their networks.
Unfortunately, the every day home user is not a network or system administrator. An operating system should not even allow this sort of behavior.
I haven’t been able to find out if this is an OLD flaw that was just exploited or if this is something NEW in the way they designed Windows 7. Seems the media is not making this very clear. I don’t run windows 7. I have a bootcamp image of XP Pro SP3.
This is an old flaw that has risen its head again. Microsoft has changed the order of the search path for .dll files with the latest SPs. Windows will then search system folders first and then the current directory last. But if the name of the .dll is unique, it will still be found in the current directory, loaded, and executed as part of the application.
WOW....
I mean most of the hacks I use just replace the actual DLL written for the App, but this is like “Hey whats’s this DLL doing here? Oh well, I’m a dumb OS, I will just load it and see what it tells me to do”.
EEEEK
There’s a special place for them, System32. It also looks in the same folder the exe was run from, which could be the desktop. This has been how Windows works since day 1, somebody just finally figured out you could stick evil dlls in the search path.
Yeah, I am getting the gist of it. Incredible. Like Tom Petty says... “there ain’t no easy way out”.
Really this is an example of you can’t protect users from themselves. If they’re dumb enough to plant an infected version of a common dll somewhere then bad things are going to happen and there’s no way to stop it. Every OS is vulnerable to trojans, if you allow the users to install good software (which of course you have to) then you’re also allowing them to install bad software.
It doesn’t load random dlls, it will only load dlls requested by an exe or dll. But those could in theory be hacked and swapped.
Hmmm... Downloading and saving a file is pretty much under the control of the user, as I stated above. It's installing the DLL in the right directory (or at least into a system folder). Either you get the user to manually copy the DLL to the proper folder, or you run a local executable (even a batch file) that will copy the file from your downloads folder to the system or application folder.
Either way, SOMEONE is "installing" the DLL in that it has to be properly positioned within your folder structure. Not in the system path or application directory - it's not loaded.
This is nothing more than a classic trojan, but is with DLLs rather than full executables. Meaning it's a partial executable (you can consider a DLL as a fraction of a program, containing executable code and data that is shared amongst multiple applications).
I'm 100% confident that if I downloaded that infected DLL to my machine, as I download everything else (to a desktop folder called "Downloads") that nothing would happen. That folder is not in the system path, nor is it in ANY path for any application. That DLL would sit there forever, never accessed or touched, because the application that normally calls it wouldn't have a CLUE to look for an alternate version in my desktop download folder.
I would have to physically move the DLL, or execute an application to move it, to a system folder or the folder of the targeted application in order for it to become a "live" infection.
You need to actually have a user dumb enough to move things around, or modify paths to cause this to be an issue. Or modify the default behavior of IE to cause it.
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.
Leave downloads in a download directory and everything will be OK. Or be smart enough to NOT download/accept DLLs and EXEs from unknown sites.
This is not about downloading and saving a file. It's about looking at data. The .dll file does not have to be in a system folder or the application folder. It doesn't even have to be on your computer. It only has to be in the folder where the data is located. If you are viewing your data from a network server, the user does not have control of where the .dll file is loaded from.
You sure you know how a DLL works, and what a system path is? I don’t think you do...
That's funny because I was thinking the same thing about you.
Every application has a current directory. Every running process has a current directory (folder is the more modern term), but back in the days of DOS, they were called directories. And to run with an application and open a data file, you could move to a directory that contained your data from the DOS prompt, for example "C:\Work\Data\", run the application from the DOS prompt (you had to run it from the command line because there were no graphical windows back them), and simply specify the data file with a relative name: "meme.txt" for example. The current directory of the application would be "C:\Work\Data", regardless of where the executable file was actually kept on the system.
Now look at this from the article:
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.
If the current directory of your application is "C:\Work\Data\" and you open an data file in that directory, and the application looks in the current directory for .dll files, and a malicious hacker has put a malicious .dll file in that directory, the system will load that .dll file and execute it as part the application's code. And that's the problem.
It's systemic, but I wouldn't call it below OS level.
Every program calls and looks for dll’s.
Mine don't specifically look for any DLLs, so wouldn't be subject to this flaw. I compile everything into the executable. I avoid P/Invoke like the plague. Of course my programs aren't quite as big as the vulnerable ones mentioned. They could indirectly call DLLs by invoking C# methods that cause the runtime to invoke DLLs, but those would be called within the .NET system to known locations. You'd need a broke .NET installation to make it vulnerable, and then that might cause the program to not run in the first place.
Yes, I am a Windows developer, and my favorite language is C#.
OK, you have confirmed you don’t understand DLLs. They don’t open in the directory of data, but the application directory or system path. That’s how it works on Windows; you MAY load a DLL when opening a file, but it’s loaded from the app folder or system path.
The paper stated they remotely forced IE to download a file to the desktop. If the user hadn't noticed the download and deleted it, the next time IE is started it would look to the desktop for its DLL, find this one, and execute it. No user intervention required. This was actually done, not theoretical.
That folder is not in the system path, nor is it in ANY path for any application.
There's no way a regular user would know that. You need disassembling or debugging tools. This stuff is hard-coded into the application. In Visual Studio it is done through the project properties. Additional paths can be added using the SetDllDirectory() function in the code. In addition to that, Windows has its own places it looks by default. It's not just the Windows directory or other normally protected locations, but includes the current directory and any directory in the PATH environment variable.
I'm 100% confident that if I downloaded that infected DLL to my machine, as I download everything else (to a desktop folder called "Downloads") that nothing would happen.
If your current directory at the time of execution is %USERPROFILE%\Desktop\Downloads, you're screwed.
DLLs are loaded from wherever they're found on the computer. Windows doesn't care, and there is no checking done for any kind of approved or secure locations. There are several methods by which any directory on the computer could be searched for a DLL.
I am a professional Windows developer, and you have confirmed you don't understand DLLs.
On the contrary. You have demonstrated beyond doubt that you do not understand how Windows programs load .dll files. And it is this lack of understanding of .dll files that leads programmers to write code that is vulnerable to loading a malicious .dll files.
Exactly.
You don't understand the Dynamic-Link Library Search Order. Here is a link to Microsoft's website where they explain the order of the search: http://msdn.microsoft.com/en-us/library/ms682586(v=VS.85).aspx.
Here are two most common possibilities for the search order:
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...
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.
Seriously, have you ever written a Windows app? This is pretty basic stuff...
By default, IE stores downloads into a “Download” directory. You need to change - as user - the path to store things, or use another browser (such as Safari, which I linked to) that stores downloads locally on the desktop. THEN you can run into this with IE.
It’s certainly not with any application trying to read data as stripes is trying to claim...
Welcome to the club; I've been programming on Windows for the better part of 2 decades as well. Apparently you've encountered a standard where DLLs are not in the application directory or the system path? Where they're kept on the desktop? If that's the standard of your shop, I'd suggest changing your practices...
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:
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.
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."
Can I persuade you to make a sizeable monetary wager on that?
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?
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.
Easily done by saving a file anywhere else just once, a common occurence. IE uses the last-saved directory for future saves.
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")Of course the shortcut properties trick works on this too.
wscript.echo wshell.currentdirectory
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.
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.
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.