Let's start with saying that the guys at Google think it's a turned on by default feature, which can be easily turned off in the options, by clicking just one checkbox. Can this then be called a bug? It was foreseen and it can be turned off. It's not a bug then.
Is it a vulnerability? James C. Slora Jr. says it is, and he even has logically sounding arguments. A sum up of what he wrote: automatic file downloading isn't an attack itself, but it creates a vector of attack, which enables other attacks to take place. As examples, he has given the desktop.ini file (but afaic one cannot to too much harm with it), files scanned by AV software (you can hear about vulnerabilities in AV software quite often), and other files that cause some action to be taken (a common example is the vulnerability related to the animated cursors that resided in .ani files).
I guess I'll add my thoughts to this. Do you remember the DLL spoofing technique? Briefly speaking, most of the executable files import some external DLL libraries. Where does the PE loader look for these libraries? This depends on whether the DLL is a system DLL, or a user DLL - and this depends on the list of known (system) DLLs. If the lib is on that list, then the loader will look for it in the System32/SysWOW64 directory. If it's not on the list, the loader will first look for it in the directory where the currently executed file is placed. An example list of system DLLs on Microsoft Windows Vista PS1 follows:
clbcatq.dll
ole32.dll
advapi32.dll
COMDLG32.dll
gdi32.dll
IERTUTIL.dll
IMAGEHLP.dll
IMM32.dll
kernel32.dll
LPK.dll
MSCTF.dll
MSVCRT.dll
NORMALIZ.dll
NSI.dll
OLEAUT32.dll
rpcrt4.dll
Setupapi.dll
SHELL32.dll
SHLWAPI.dll
URLMON.dll
user32.dll
USP10.dll
WININET.dll
WLDAP32.dll
WS2_32.dll
It's important to note that on XP there was another DLL called VERSION.DLL, but on Vista it's no more present on the list. It's also important to mark that all the libraries imported by the above DLLs are also considered to be system DLLs.
OK, not let's pretend a user enters some malicious website using Chrome, and without any confirmations three libraries are downloaded - VERSION.DLL, WS2_32.DLL and WSOCK32.DLL - and all there contain malicious code.
The user doesn't notice / forgets, and goes on. In a day, maybe two, the user downloads himself, let's say.. the newest Blender installation file, and he stats to install it.
And here is where the trap is triggered - the Blender install file imports VERSION.DLL, which is NOT on Vistas system library list, it means that the VERSION.DLL planted earlier will be executed. What happens later is just to horrifying to write ;>
By the way...
On 22nd Nov'24 we're running a webinar called "CVEs of SSH" – it's free, but requires sign up: https://hexarcana.ch/workshops/cves-of-ssh (Dan from HexArcana is the speaker).
I'll just add that Blender install isn't an exception. I've checked just a few install files that were present in my download directory, and half of them imported some user DLL. As an example I can give Open Office (UX version) install, and WGA plugin installation file (it's the anti-piracy plugin from Microsoft for FF).
In the example above I've said also about WS2_32.DLL and WSOCK32.DLL. Let's say that the user doesn't download an installation file, but he downloads some ready to run application, like some very popular SSH client - putty. Putty imports WSOCK32.DLL, so guess what happens next.
To sum up this post: imho this feature is indirectly dangerous, and should be either turned off by default, or there should be an option to set a list of trusted (PDF?) and untrusted (DLL? EXE?) file types.
PS. There showed up another exploit for Chrome on milw0rm, this time, it's also remote DoS, and it also requires user interaction. It's probably a buffer overflow in Inspect Element (isn't this the second bug in Inspector? I have already written about one).
Comments:
I'm not sure that attack you described might actually work. There is registry key called "SafeDllSearchMode" that will prevent this. And it's enabled by default in Windows XP2 (and possibly newer Windows). Yes, there are some known "defects" with this reg key and IE (a.k.a. "blended threat" issue).
http://msdn.microsoft.com/en-us/library/ms682586.aspx
I just downloaded Chrome v0.2.149.29, and it still automatically downloads DLL files. Yes, the user is notified of the download, but the download still takes place by default. I'm using a standard PHP download script to test it btw, not the location/iframe scripts provided as PoC by the researchers at FD/bugtraq.
The download script looks like this:
<?php
$ctype = "application/octet-stream";
$totalname = 'test.dll';
// File size
$filesize = filesize($totalname);
$filename = $totalname;
// OK Setup header
header("Expires: 0");
header("Content-Type: $ctype");
header("Content-Disposition: attachment; filename="".$filename."";" );
header("Content-Transfer-Encoding: binary");
header("Content-Length: ".$filesize);
readfile($totalname);
exit();
?>
(Ignore it's strangeness, I made if from some old script I had someplace)
As for XP SP2 goes, well the VERSION.DLL attack won't work there, since as I have written, VERSION.DLL is a system DLL on systems prior to Vista. However there are other DLLs that can be used (like the winsock ones).
I have tested the VERSION.DLL attack vector on Vista, and it gets executed.
As for the SafeDllSearchMode, please note the difference (stated in the link You have provided) between when it is enabled, and when it is disabled. The first point is the most important one:
When enabled: 1. The directory from which the application loaded.
When disabled: 1. The directory from which the application loaded.
Well, it's the same. And in both cases the first point is the dir where the executable is placed - the download directory, where the malicious DLL is placed.
So I'm affraid that SafeDllSearchMode won't help ;<
you were right about SafeDllSearchMode :). Just tested putty/ws2_32.dll on XP SP3 + Chrome 0.2.149.29 and it worked like a charm. So I guess carpet bombing/file download are just partially patched.
Looks like it's still not properly addressed in 0.2.149.30. Huh ;>
Add a comment: