Chrome: trick users into giving access to all files on local disk (2016) | Hacker News Reader

Chrome: trick users into giving access to all files on local disk (2016)

bugs.chromium.org

78 pointsbcaa7f3a8bbc24 comments

The use of the word "trick" here is well-warranted. This is really more of a UI thing (i.e. it's a little too easy for a user to accidentally click "Ok"). Applications have responded to concerns like this by just having the "Ok" button be non-clickable for a full second after appearing.

Ah, so that must be why there's sometimes a delay to click to accept a download in Firefox!

Yup, you can change it in about:config under security.dialog_enable_delay. But here's a blog post from 2004 showing how easy it is to exploit a user if you turn it off. http://www.squarefree.com/2004/07/01/race-conditions-in-secu...

So, this was a known exploit before Chrome even existed...

I tested the demo and it seems the associated javascript function to prompt someone to install a software is no longer present in Firefox (netscape.security.PrivilegeManager.enablePrivilege).

I question the utility of having this delay behaviour by default, worst that can happen is you accidentally start a download AFAIK, which you can just quickly delete/cancel afterwards.

And, there's browser.download.manager.alertOnEXEOpen too.

I much prefer Chrome's behaviour of starting the download and you instantly can see the filename and size in the bottom as soon as it starts and can then choose to either open it or show it in the file manager.

> worst that can happen is you accidentally start a download

There's a potential DLL hijacking attack:

1. Accidental download of kernel32.dll

2. Ignore, who cares, do something else

3. Download actually_wanted_installer.exe, which finds malicious kernel32.dll in current directory instead of SYSTEM32

There are a few DLLs whitelisted for protection for this, but drive-by downloads are a real attack vector.

Also in the past, exploitable bugs in the thumbnailer if you browse to your Downloads directory (e.g. CVE-2017-11421 and others on Linux).

Opening documents is still dangerous, even if there is no option to ask for installations. Alert on exe is not nearly enough. Almost any file type is dangerous on Windows, and there is a long list for unixes. Making it possible for users to open a document without knowing what they are doing first is a huge vulnerability.

That said, starting the download and immediately getting it out of the user's face, requiring interaction to open them is a very good solution. It leads to some problems on Windows, but then, what doesn't?

SO it _isn't_ a bug after all. I've been perplexed by this behavior for quite some time.

That delay should always be there, even when the window regains focus after being out of focus. You just usually don't notice it, because it's usually already done until you have your mouse on the button.

Personally I'm using firejail (and drop Chrome since few months) so... In any case the problem of modern browsers is that they are monster with a so big and so "closely developed" codebase that even if open no one, perhaps many devs included, really know it enough. And the trend is more and more to add features...

+1 for firejail. I cannot even imagine running a browser without putting it in a sandbox.

chrome runs in a sandbox though, using the same techniques as firejail

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/l...

Apparently not the same technique since this CVE is a thing that allows access to user files. The only thing I've permitted the browser on my computer to 'see' in ~/ is a 'Downloads' directory. When I open 'file:///home/craftyguy' in the browser, it's literally the only thing it sees. Furthermore, it can write whatever it wants to ~/, but that's just a tmpfs filesystem that goes away when the process dies.

> fortunately, on Linux, the exploit (even the limited one in #2) simply crashes Chrome after grinding for a while.

This is the title of the bug:

Security: Read all local files using minimal user interaction and gesture laundering

The title here on HN should include some combination of "bug", "security", "fixed", and "gesture laundering". The way it's written now sounds like Chrome's designers are _trying_ to trick users into giving file access permissions. That's not the case.

I'm confused what happens here. Sure, you are tricked into pressing Return in a file open dialog. But you can't open the “file” `C:\`… right? Does that somehow let the page access files on the disk?

The file dialog allows opening of folders as well, so the exploit is basically tricking the user into saying "I want to upload the folder C:\"

The beginning of a new class of user-interface attack?

This isn't really new -- things like temporarily-disabled buttons on dialogs were added as much for this reason as to prevent accidental input -- but it certainly remans prevalent.

From a comment posted Dec 5, 2017:

> This is one of our oldest open security bugs (480 days). We really need to get progress on it.

Fixed in v.66?

yep, but it's not fixed on firefox

Firejail/capsicum are your friends :-)

It wasn't ever an actual problem there?

It has the countdown before you can click OK, so with the user holding down Enter for 5 seconds, you'd not even get a handful of files, and it blocks the file dialog from "untrusted" sites.

Reply on news.ycombinator.com