Hacker News Reader

Comment by ChrisSD | Hacker News Reader

Perhaps this should be addressed but the fact it requires the user to download and open a file means it's of limited use to attackers. If you can persuade a user to do that then you needn't bother with browser exploits to get access to a user's files.

Edit: but wait, it can only access the directory the file was downloaded to? So that's almost certainly restricted to the user's download folder. That makes even less useful.

View on HN

The downloads folder is a perfect target actually. Lots of documents end up downloaded as pdfs, I certainly have enough documents to dox me. Anyone who does their e-mailing through a browser will most likely have a bunch of exciting attachments in their downloads folder.

You'll probably also find a bunch of installers in the downloads folder, I could imagine a sophisticated attacker looking for installer .msi's or .exe's for software which is known to have vulnerability.

Sure but you can get much more if you use a more exploitable file type in the first place. Why would you willing jump back into a browser's sandbox when you've just persuaded the user to bypass it entirely?

It's not so much why someone would choose this over that, as it is what attack vectors are added to which surface. Why wouldn't a bad actor be willing to jump back into a leaky sandbox?

Because they already have the run of the user's profile. Why add additional complexity for less access?

Because you may of had zero access rather than some, for example a web dev who wouldn't click on an .exe but would open an .html file without a second thought. More access isn't necessarily always the end goal either.

If someone is knowledgeable enough to not open a shady exe file, they'll probably not simply open any shady files, including doc, ppt, and html

Nah, people are dumb (exhibit A: myself) and overly trusting of parsers/sandoxes.

Not true for html files. They are widely regarded as harmless.

I have never seen anyone saying HTML files are harmless, and would definitely never say it myself.

Easy solution: Firefox gets two sandbox modes for file://;

If the directory is a subdirectory or top level to the default Download Directory or a recent "Save To.." location then the file will be sandboxed like in Chrome and show a warning.

If outside any such directories, it works as normal.

Does the vulnerability permit access to a directory index, in order to identify the filenames of exciting attachments to transmit?

Apparently not. You can create a test.html file with the following content:

    <script>
      fetch(".").then(r => console.log(r));
      fetch("/").then(r => console.log(r));
    </script>

The console show errors when these URLs are loaded:

    TypeError: NetworkError when attempting to fetch resource. test.html:2:1

Yeah. The Downloads directory inevitably accumulates sensitive data over time, especially lacking automatic cleanup/expiration of files. For this reason alone, Firefox should follow the Chromium/Edge policy.

Running Firefox via snapcraft, I've come to realize that desktop Linux systems keep moving the problem around without fully solving it (though I'm quite grateful for the real security benefits of snaps).

Traditional users/permissions are ineffective because all your important data is readable by your ostensibly unprivileged user.

Then SELinux/AppArmor enforcement comes along, but it's of limited effectiveness because you end up with free-for-alls (for convenience's sake) like ~/Downloads.

I think SELinux/AppArmor is a good idea for services like web/ftp/irc/ssh servers, wayland compositors, notification daemons (like dunst), external devices managment daemons (like udiskie) etc. But it isn't a good solution for applications which a user could try to use to read or change arbitrary things in the system for no malicious reasons. But, as I understand it, the Flatpak model of having the application sandboxed and then only allowing it to access files which are selected by the user in the GTK dialog is a great solution. It's just that I haven't seen one for command line applications. E.g. how should we protect ourselves from someone exploiting a vulnerability in vim to access our private documents, which we could potentially want to edit with vim ourselves?

EDIT: it seems there is some progress on making a Firefox Flatpak: https://bugzilla.mozilla.org/show_bug.cgi?id=1441922

> Yeah. The Downloads directory inevitably accumulates sensitive data over time, especially lacking automatic cleanup/expiration of files. For this reason alone, Firefox should follow the Chromium/Edge policy.

> Then SELinux/AppArmor enforcement comes along, but it's of limited effectiveness because you end up with free-for-alls (for convenience's sake) like ~/Downloads.

I keep this clean when I am finished with a file I usually have a term up and will move it to somewhere in ~/ or ~/Documents

I think I might use AppAmor to secure this like TAILS does https://tails.boum.org/contribute/design/application_isolati...

I found these profiles which will act as a good basis https://github.com/mk-fg/apparmor-profiles/blob/master/profi... it seems that Mike Kazantsev (mk-fg) has abstracted it it a bit more into other files.

The ones that come with apparmor look ancient https://gitlab.com/apparmor/apparmor/blob/master/profiles/ap...

> E.g. how should we protect ourselves from someone exploiting a vulnerability in vim to access our private documents, which we could potentially want to edit with vim ourselves?

I think for me it would be about starting with high risk applications.

If you look at https://github.com/mk-fg/apparmor-profiles/tree/master/profi... you notice things like steam, skype, etc.

But still seems horrible to me.

If you're supposed to peer review the static web page designed by your coworker (the one who was hacked), it may steal things from your work folder.

Reply on news.ycombinator.com