Unix Sysadmin Anyone?
Unix sysadmins have known for years not to include the pwd in their execution path or library path. So where has Microsoft been for the last 30 years?
A day after Microsoft confirmed a vulnerability in Windows applications that executes malicious code on end-user PCs, the first exploits have been released targeting programs including the Firefox browser, uTorrent BitTorrent client, and Microsoft PowerPoint. The attack code was posted on Tuesday to the Exploit Database. It …
I see your "security feature" and raise you:
That's an OS security feature in much the same way as turning off SSID broadcast "secures" your wireless LAN (i.e. anyone with the smarts to produce an exploit for the f***ing thing ain't even going to break step bypassing it).
"Microsoft said on Monday that the flaw stems from applications that don't explicitly state the full path name of DLL files and other binaries associated with the program"
The entire point of DLL files and shared code is that your apps DON'T need to know or care where it is. Explicit full paths sound like an amateurish mistake. Reminds me of how my C:\WinNT folder was enough to break many Win95 viruses that expected C:\Windows. A few crappy applications would end up creating a \Windows folder and dropping their crap there because they didn't know how to use WinDir/WinSysDir.
This post has been deleted by a moderator
This is an exploit that works because of the design of the OS. It's not really a flaw per say and doesn't just affect Windows but Linux, Unix, Mac OS and nearly every other OS out there.
I suppose they could mitigate this issue by not allowing code outside the program files folder to execute and not allowing non-administrators from installing programs into Program Files.
I suppose the other thing they could do is run all native applications inside a sandbox, which would be a more complete solution. I expect Microsoft to do that at some point in the future, maybe the version of Windows after 8 or the one after. I'm sure they'll be forcing us to switch everything to .NET (which doesn't suffer this issue itself) eventually.
It's logical, relatively safe, and potentially useful for an application to use DLLs placed its own folder preferentially. It's not logical, safe, or very useful (except maliciously) for an application to use DLLs from the folder of the data file you're trying to open. If I understand correctly, the latter is what's happening.
I can imagine how it worked out that way, but there's really no good reason for it to do that.
It sounds to me like MS would be wise to issue a voluntary patch, which they would indicate would be a forced patch at some date in the future (e.g., January 1, 2011) and give app developers the time to fix their code. In conjunction with the auditing tools, this ought to allow IT folks to determine what is at risk, and allow developers time to resolve the issue --and it ought to prod more complacent developers into fixing their code rather than letting this slide.
> It's not really a flaw per say and doesn't just affect Windows but Linux,
> Unix, Mac OS and nearly every other OS out there.
Unix looks for system libraries in $PWD? News to me.
You know that funny looking file layout that the rest of you weenies like to make fun of. It's designed to specifically avoid precisely this sort of situation.
Executables are in one place. Libraries are in another. User data is in yet another.
"MS said that the flaw stems from applications that don't explicitly state the full path name of DLL files and other binaries. As a result, each application will have to be patched separately..."
It sure sounds like MS is saying "it's not a bug, it's a feature"
When hundreds or thousands of existing apps can accidently wreck the OS.. It's a problem in the OS, not the apps.
MS needs to put out a patch for the underlying problem, even if it means breaking hundreds of third party apps.
Hopefully some antivirus company will put out an update soon, that starts flagging half the apps on the computer.
this has been a "feature" of Windows for a long, long time. It was a way that you could assure that your program had the EXACT DLL that it needed, not an older or new version. Put the DLLs you absolutely HAD to have (iow - the ones where you'd carefully coded around their bugs/undocumented calls/etc) in the same directory as your EXE and when your EXE goes to load the DLLs, Windows will magically have it load the ones in the same folder as your EXE instead of any others.
What I'm wondering is if this only applies to DLLs, or if it's also exploitable with VBXes/OCXes as well. Guess I'm too lazy to be arsed to read the tech docs and find out.
When you click on a data file, Windows sets the cwd to the directory to the data file's directory is and launches the associated program and the program then searches directories for DLLs and the cwd is included in that search.
If programs hardcode the cwd in the DLL loader (which is what it looks like), I'm sure Windows could set the cwd to the executable's directory and pass the full pathname to the program.
So why are MS saying they can't fix this in Windows? Because it looks untidy in the file explorer when you later save the data file as it's pointing to the executable's directory?
a VBX is a DLL. It uses the DLL loading mechanism, and is subject to the same exploits.
an OCX is a COM object. It uses the COM loading mechanism, which requires registration.
HOWEVER, they've invented this thing called "registration free COM", which depends on things like the Activation Context, and the Manifest, which could easily conceal security leaks.
(Also, an OCX may also be a classic DLL, for interoperability with some non-COM thing)
i need to install a mac's anti virus!
If you're a Mac user - you probably don't know how. Seemingly grammar is beyond your grasp so software installation must work by magic pixie power.
Sorry, couldn't resist.
Now can we all please stop the silly "My OS is better than your OS" willy-waving please?
This post has been deleted by its author
The whole point behind the way windows originally loaded it's dll's was so that you didn't have a million different versions of the same thing on your machine at once and everyone was supposed to just use the 'latest' one. Then people complained about the fact that their apps only ran with specific versions of the dll and that legacy apps couldn't always be updated to go with the new versions of dlls released by other people so they made it so you could include the specific ones in your program directory and windows would look there first.
It's a simple case of it not being very well thought out in the first place and badly stuck together with card and bits of string ever since.
"The whole point behind the way windows originally loaded it's dll's was so that you didn't have a million different versions of the same thing on your machine at once and everyone was supposed to just use the 'latest' one. Then people complained about the fact that their apps only ran with specific versions of the dll and that legacy apps couldn't always be updated to go with the new versions of dlls released by other people so they made it so you could include the specific ones in your program directory and windows would look there first."
And they did that rather than including some sort of version numbering system for DLL's
Lazy, lazy FAIL!
> The whole point behind the way windows originally loaded it's dll's was so that you didn't have a million different versions .. so they made it so you could include the specific ones in your program directory and windows would look there first."
The original reason for `the way windows originally loaded it's dll's' was because MS put system calls in Dynamically Loaded Libraries, not a good idea, and at the time at least one microsfotie said so. I recall reading some such in the Comes documents.
@Simpson: MS have the right idea on their response IMO; they've released a QFE update that gives users/admins the *choice* of disabling the DLL calls from the working directory path, or limiting the DLL calls depending on which executable image is being run and/or where that program has been launched from. Can you imagine the outcry if they had just pushed out a major change to the OS that "broke hundreds of third party apps"?!
Microsoft has posted an hotfix that disable loading from the "current" directory. But because it changes the way DLLs are loaded system wide, it can break ill-behaved application that rely on on the old behaviour. One of the main Windows issues is that there are too many developers writing applications in the wrong way - they learned to code in DOS and never improved from there.
This is yet another design flaw in Windows, a Unix system will not do this unless you explicitly set the LD_LIBRARY_PATH variable to point to the current directory which is not a default on any system i'm aware of.
As for developers being expected to code in the full path to the library? (which sounds like a really crufty workaround) Surely it's the linker which should specify this, and by specifying a full path you're going to make it more difficult to install the application anywhere other than the default location.
If they do fix this then it will significantly break compatibility. This is yet another reason why the windows design is fundamentally flawed and is one of many security flaws which cannot be fixed without breaking compatibility. However, compatibility is really the only selling point of windows so these poor design decisions are going to be hurting millions of people for years to come.
Windows will look in the same location as the exe first for its libraries. Then it'll go looking in everything in the PATH and the current directory. Since the loader doesn't use absolute paths (it can't because it doesn't know where the app is installed anyway) then this affects everything.. in fact I've used it myself to poke into applications to make them load my versions of things. That isn't even fixable without a major change to the executable file format.
btw. 'Same directory as the exe' also counts if you're writing a library, control panel, or screen saver, which aren't exes themselves.. it's the calling app that determines the search path then.
You can do exactly the same thing in Linux setting LD_LIBRARY_PATH or even LD_PRELOAD and pretty much any other unix has an equivalent mechanism.
Picking on LoadLibrary is barely the tip of the iceberg.. especially when that has *documented behaviour* to search specific directories including the exe directory (there's even a way to use an alternate search path). The LoadLibrary 'issue' also effects *every* app that uses delayload DLLs, which is, well, probably millions..
But really I have my doubts whether I'd call it a vulnerability. It's the way windows has been documented to work since at least 3.0 that I know of... probably long before that.
1) you download a zip file that purports to be a copy of "some media" you wanted to view, maybe a PDF, maybe an mp3 or .mov. When you unzip it, the directory contains the file you wanted to see (could be a real version), a readme.txt, some html links, and a few libraries (like usedbypopularmediaplayer.dll). Knowing windows, those files might be hidden/system and would still work. When you open the dpf/mp3/mov, it runs stuff from the shipped library, and you get hacked. Even better would be a zip file that when opened contains another zip file and some libraries like usedbypopularzipprogram.dll.
In this case, yes, you downloaded stuff from the internet and opened it in windows, more fool you.
However, people are less careful when running media files or opening zip files, especially when its an established format with no current vulnerabilities.
2) At work you use a network drive full of (say) microsoft word documents that you open on a regular basis.
Someone (or a virus on someones system) with write access to the network drive drops a couple of dlls (usedbymicrosoftword.dll, usedbyopenoffice.dll) into that directory. Suddenly, everyone that opens a file from there gets infected, but your antivirus doesnt pick up anything wrong with the documents themselves.
3) As 2), but the dll is dropped on removable media in a directory containing media files accessed by viewers known to be vulnerable. Said media is copied a billion times and handed out at a security conference by a major corporate. Although those that access the media probably have all the autorun stuff disabled, and scan the files for viruses, they still get caught when they open the media files.
My Atari STe used to have a folder for each program, and everything that program needed was in the folder.
No registry, no path, just the folder - and the OS of course, but that just did OS things, manage memory, provide a GUI - you know, OS things.
Simpler days I guess, but maybe Microsoft has been trying to make a popular OS, not a secure one.
can someone tell me how the malecious DLL gets onto the machine in the first place? If it's the same old thing of 'opening an untrusted program' , 'clicking a link in an email' or 'visiting an dodgy website' then presumably all my existing precautions will continue to keep me (relatively) safe...
CCP did something like this with an EVE Online patch once. Part of the EVE client features a file called "boot.ini" and an incorrect path during an update caused systems with the client installed on a drive other than C to accidentally update c:\boot.ini rather than <evepath>\boot.ini. Ooops.
The problem with "hard coding" DLL locations in an EXE is that you then have to isntall the exe on the same location on every PC ever, which breaks it for anyone with multiple partitions or running programs off network drives or whatever. Course, having a program look for DLL files in the data directory you just opened a file from seems silly.
Easily avoided by not downloading data files that come with free DLLs.
Q. .DLLs have advantages over .EXE’s in terms of performance and flexibility, but doesn’t the OCX architecture take us back to where we were with Win16 in terms of programs (in this case components) impacting each others’ integrity? Also: isn’t this an incredibly powerful opportunity for those writing Trojan horses, viruses, etc?
A security flaw. Lets all have an argument about how shit ms is and how superior linux is and then counter arguments. Exploits and security issues happen every day to all OS's with any significant user base. Who gives a damn, patch your system and move on.
Mine is the coat with beer money in the pocket. See you all at the pub.
is that apparently the vulnerability arises when the application tries to load Whichever.DLL that doesn't exist in any other directory including the application's own directory, then Windows will look in current worwing directory, i.e. where you just loaded a document from. But why is the application trying to load a DLL that doesn't exist except in the insecure cwd / malicious location?
Would explaining it to me, make it easier for people to hack computers, including mine?
The KB article, http://support.microsoft.com/kb/2264107, states that a DLL load will look in the directory from which the application loaded, the system directory, the 16-bit system directory and the Windows directory _before_ it looks in the CWD. So, unless it's expecting the DLL to be somewhere in PATH (which is checked after CWD), what is it that is causing the application to load a DLL from CWD? On my system, W7, I can't see anything in the PATH that might be relevant to Firefox which is listed as vulnerable.
As mentioned elsewhere, KB2264107 includes a patch to fix the issue for badly written apps, and those apps can be properly fixed at some point.
There will be very few issues that 'can't be fixed'. Microsoft work very hard to retain backwards compatibility for applications. There's things like the Application Compatibility Toolkit that applies shims to certain apps to retain buggy side effects of old APIs, or to default to pretending a certain version of Windows is installed for instance. There's multiple types of memory heap, which are applied to some particularly old leaky apps.
'All' Microsoft has to do for the worst offenders is to add a new update with a Windows DLL compatibility shim, add new settings to the system defined compatibility database, and the problem goes away. Whilst they're busy doing that, the existing patch will mitigate the problem.
Sure, the DLL search feature is an issue, but when Windows was created every arsehole in existance wasn't trying to break your system and damned near universal WAN connectivity was a dream for most. To give another example, FTP is still around, and that's a prime example of a protocol created when the assumption was that everyone had honest intentions.
Think of a drive-by website advert....
visit-1 to the web page loads a fake image called something-unique.dll. IE or any browser will save this in the temporary web cache. An action which is normally safe in and of itself, even the good browsers will do this before identifying that the object is not an image and to be ignored for security.
visit-2, or even an advert at the end of the page, loads something IE etc interprets as an executable. When loading its CWD is the same temporary cache folder which has a something-unique.dll sitting there waiting to be loaded into DLL memory space. something-unique.dll does not exist in the system elsewhere so the CWD one gets loaded and the system turns to mush.
This is pretty much the standard windows attack vector for every single virus you see announced with the words "or click on a link". There are closing on 400,000 viruses which do this today.
I use IE as the example, but any software running on windows which downloads files and executes (including the folder explorer and help system) does this in one form or another.
Biting the hand that feeds IT © 1998–2020