4 ms·

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

78 points by bcaa7f3a8bbc 8y ago

bcaa7f3a8bbc 8y ago
The beginning of a new class of user-interface attack?
- JeremyBanks 8y ago
  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.
  - deleted 8y ago
    [deleted]
- ssalka 8y ago
  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.
deleted 8y ago
[deleted]
Piskvorrr 8y ago
Fixed in v.66?
- gruez 8y ago
  yep, but it's not fixed on firefox
  - xte 8y ago
    Firejail/capsicum are your friends :-)
  - Sylos 8y ago
    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.
craftyguy 8y ago
> fortunately, on Linux, the exploit (even the limited one in #2) simply crashes Chrome after grinding for a while.
Derek_MK 8y ago
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.
- abrowne 8y ago
  Ah, so that must be why there's sometimes a delay to click to accept a download in Firefox!
  - sp332 8y ago
    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-security-dialogs/ http://www.squarefree.com/2004/07/01/race-conditions-in-secu...
    - Sylos 8y ago
      So, this was a known exploit before Chrome even existed...
    - feikname 8y ago
      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.
      - mappu 8y ago
        > 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).
xte 8y ago
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...
- craftyguy 8y ago
  +1 for firejail. I cannot even imagine running a browser without putting it in a sandbox.
  - blibble 8y ago
    chrome runs in a sandbox though, using the same techniques as firejail https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux_sandboxing.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/l...
    - craftyguy 8y ago
      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.
TazeTSchnitzel 8y ago
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?
- andrewguenther 8y ago
  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:\"
bsimpson 8y ago
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.

78 points by bcaa7f3a8bbc 8y ago

bcaa7f3a8bbc 8y ago

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

JeremyBanks 8y ago
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.
- deleted 8y ago
  [deleted]
ssalka 8y ago
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.

deleted 8y ago

[deleted]

Piskvorrr 8y ago

Fixed in v.66?

gruez 8y ago
yep, but it's not fixed on firefox
- xte 8y ago
  Firejail/capsicum are your friends :-)
- Sylos 8y ago
  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.

craftyguy 8y ago

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

Derek_MK 8y ago

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.

abrowne 8y ago
Ah, so that must be why there's sometimes a delay to click to accept a download in Firefox!
- sp332 8y ago
  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-security-dialogs/ http://www.squarefree.com/2004/07/01/race-conditions-in-secu...
  - Sylos 8y ago
    So, this was a known exploit before Chrome even existed...
  - feikname 8y ago
    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.
    - mappu 8y ago
      > 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).

xte 8y ago

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

craftyguy 8y ago
+1 for firejail. I cannot even imagine running a browser without putting it in a sandbox.
- blibble 8y ago
  chrome runs in a sandbox though, using the same techniques as firejail https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux_sandboxing.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/l...
  - craftyguy 8y ago
    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.

TazeTSchnitzel 8y ago

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?

andrewguenther 8y ago
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:\"

bsimpson 8y ago

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.