Yesterday another method of making Google Chrome automatically download a file was posted on bugtraq. Of course an old discussion was restarted - is automatic file download a bug, feature, or a vulnerability?

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 ;>

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).