Posted on 08/24/2010 11:30:28 AM PDT by stripes1776
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...
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.