4 ms·

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 the

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.

ChrisSD 7y ago
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?
- Tiki 7y ago
  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?
  - ChrisSD 7y ago
    Because they already have the run of the user's profile. Why add additional complexity for less access?
    - Tiki 7y ago
      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.
      - dejaime 7y ago
        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
        pas 7y ago
        Nah, people are dumb (exhibit A: myself) and overly trusting of parsers/sandoxes.
        posix_me_less 7y ago
        Not true for html files. They are widely regarded as harmless.
        dejaime 7y ago
        I have never seen anyone saying HTML files are harmless, and would definitely never say it myself.
regecks 7y ago
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.
- yakubin 7y ago
  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 https://bugzilla.mozilla.org/show_bug.cgi?id=1441922
  - dngray 7y ago
    > 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_isolation/#index1h2 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/profiles/usr.bin.firefox 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/apparmor/profiles/extras/usr.lib.firefox.firefox 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/profiles https://github.com/mk-fg/apparmor-profiles/tree/master/profi... you notice things like steam, skype, etc.
floatingatoll 7y ago
Does the vulnerability permit access to a directory index, in order to identify the filenames of exciting attachments to transmit?
- ayosec 7y ago
  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
zaarn 7y ago
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.

ChrisSD 7y ago

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?

Tiki 7y ago
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?
- ChrisSD 7y ago
  Because they already have the run of the user's profile. Why add additional complexity for less access?
  - Tiki 7y ago
    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.
    - dejaime 7y ago
      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
      - pas 7y ago
        Nah, people are dumb (exhibit A: myself) and overly trusting of parsers/sandoxes.
      - posix_me_less 7y ago
        Not true for html files. They are widely regarded as harmless.
        dejaime 7y ago
        I have never seen anyone saying HTML files are harmless, and would definitely never say it myself.

regecks 7y ago

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.

yakubin 7y ago
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 https://bugzilla.mozilla.org/show_bug.cgi?id=1441922
- dngray 7y ago
  > 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_isolation/#index1h2 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/profiles/usr.bin.firefox 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/apparmor/profiles/extras/usr.lib.firefox.firefox 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/profiles https://github.com/mk-fg/apparmor-profiles/tree/master/profi... you notice things like steam, skype, etc.

floatingatoll 7y ago

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

ayosec 7y ago
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

zaarn 7y ago

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.