8 ms·

Firefox Local Files Theft – Not Patched Yet

114 points by akeck 7y ago

ChrisSD 7y ago
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.
- daxterspeed 7y ago
  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.
- VitoVan 7y ago
  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.
kevingadd 7y ago
Compatible with spec and previously a feature. I agree that it should be patched but Chrome's policy has historically made local web development and testing a pain in the ass because now you have to configure a web server correctly and work around Chrome's broken cache-control policy (have fun ctrl-f5'ing all the time or opening devtools to disable cache, which deoptimizes your JS) I struggled with this for years and opened multiple bugs about it. If you're trying to release software to end-users that requires them to configure a whole damn web server you get really tired of it. Disabling content loading from file:// is one solution, but I feel like the 'this was loaded from the internet' flag already used for downloaded EXEs and DLLs is a perfectly reasonable alternative that would work just as well without breaking things for local development. (To be clear, you don't offer the option to bypass that, since it would only be a security vulnerability)
- ChrisSD 7y ago
  Does`python -m http.server 8000` not work for local development?
  - kevingadd 7y ago
    You need way more configuration than that, python's http server doesn't handle keepalive and threading correctly (or didn't when I last used it, maybe that's fixed in 3). I historically had to use IIS or Apache, and at work we used a full Apache install. If you used python your performance was much worse if your application worked at all. For C# apps you can at least just spin up a HTTPD directly in your app using system APIs, but it's also kind of flaky.
    - ChrisSD 7y ago
      I'm just surprised that file:// works better (when it's allowed).
      - kevingadd 7y ago
        It was very fast, at least for a while. It might be slow now.
est31 7y ago
IMO, the approach taken by Chrome and other browsers is over restrictive, basically killing off the file:// protocol. Already now it's impossible to load wasm files in the file:// protocol in Chrome, and I think this also had implications on using wasm in electon. Ultimately, file:// is a great, cloud free method of having web pages and applications and it should stay that way instead of forcing everything to be networked and reliant on third party computers or domain names. There are so many reports, documents, etc that live as non-networked html files. E.g. rust documentation (cargo doc --open) is generated as html files on-disk and then just displayed without the need for a webserver. Starting a localhost webserver is in fact less secure than file because now every user on the computer has access instead of just the users with read-access to the files. This has thankfully been fixed in Chrome OS though. Responsive web apps are not the solution as they still need "seeding" via the network. Maybe some kind of standardized format where you have a glorified zip file with some metadata and when you double click it, it opens in the web browser which starts a web server in the background that runs a specially designated js in that zip file and which can accept usual fetch requests and has read access to the entire zip file. The browser's "UI" would then communicate with the server via well-known protocols.
- kevingadd 7y ago
  It ends up definitely being a tax on developer efficiency overall. It also makes web development more hostile to newbies because they have to figure out how to configure a server or hop into some third-party toolset on the web to start experimenting. With the tendency to ban use of new features on non-HTTPS origins (hi again, Chrome) a newbie developer will soon have to have both a server and a https cert before they can even start experimenting. If they host on a third-party https domain now third parties are responsible for malware that might get hosted there. It just sucks.
  - codedokode 7y ago
    Regarding HTTPS, localhost is considered a "secure" origin: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts#When_is_a_context_considered_secure https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
techntoke 7y ago
Mozilla's latest tactic appears to be to trash Chrome semi-weekly on HN and then try to bring in users to Firefox. Then, later that week a new vulnerability is discovered in Firefox.
- dang 7y ago
  This breaks the site guidelines by being flamebait, by insinuating astroturfing, and by using HN threads to fight some sort of pre-existing battle. You've done this before, and we've had to warn you before. If you keep doing it we're going to have to ban you, so please stop. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
garaetjjte 7y ago
Killing javascript access to file:// would be annoying for quick experimenting. Maybe denying network access to locally loaded JS, so that nothing could be transferred out is possible solution?
- tomatsu 7y ago
  You need to spin up a server if you want to use modules anyways. Well, it's not a big deal. Just run `python3 -m http.server` or install "http-server" via npm.
  - ajsnigrutin 7y ago
    This is not something a kid learning basic html/js can do easily, since he probably uses windows, and doesn't even know how to navigate in the command prompt. The "click on the html file on the desktop" just works(TM)
deleted 7y ago
[deleted]
jasonhansel 7y ago
Can we at least disallow iframes containing file:// URIs? Essentially treat them as if they had X-Frame-Option: DENY.
usr1106 7y ago
I am not a Web programmer, so what I suggest might be nonsense. Please correct constructively :) The central statement seems to be: > “Our implementation of the Same Origin Policy allows every file:// URL to get access to files in the same folder and subfolders.” What about the following simple mitigations: * Access by file:// URL to the root and user's home directory proper are forbidden by the browser implementation (Because all subdirectories of the home directory is always a bad idea, root even worse so) Hard-coded, error dialog, period, no way to override short of patching the browser or mounting trickeries. * Access to any other subdirectories is allowed, but will cause a warning that by proceeding you grant access to the directory and all it's subdirectories. The warning cannot be suppressed by normal settings, but appears only once a day. An average user will not get it frequently, so there is a chance that they read it (and if they click OK without reading it's their problem). And for the Web developer clicking once per day is still easier than configuring an Apache. And ideally they know why they are clicking it.
Tharkun 7y ago
Another good reason to use Firejail. You tell it which folders FF gets to access, and Bob's your uncle.
- OJFord 7y ago
  But if this is only leaking the directory you choose to download, Bob's already your uncle? Issue is that people don't and don't want to choose a fresh/clean-enough directory every download.
- grapeli23 7y ago
  It's easier to create a new user account and run firefox from it. Something like: xhost +si:localuser:firefox && su - firefox -c 'DISPLAY=:0 HOME=/home/firefox firefox 2>/dev/null' && xhost -
  - Tharkun 7y ago
    Yeah, because that's a lot easier than just running "firejail firefox".. And does your snippet work on Wayland?
cesnja 7y ago
To avoid this, I use Firejail [1] with a custom rule set to limit the browser's access only to Downloads and its own profile folder. Does anybody know of anything similar for MacOS? [1] https://firejail.wordpress.com/ https://firejail.wordpress.com/
- Liquid_Fire 7y ago
  From the article, access is already limited to the directory in which the HTML file is located, so this wouldn't help. Either it would be in the Downloads directory, where it already has access, or it would be in another directory and you wouldn't be able to open the file at all unless you disable your sandbox.
mmis1000 7y ago
So, what is it different to download random exe and execute it? Isn't that accessible by design as the dir html allocated is also the root path of that page? Beside that, aren't both windows and macos warn you when you open random file downloaded from internet?

114 points by akeck 7y ago

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.

daxterspeed 7y ago
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.
VitoVan 7y ago
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.

kevingadd 7y ago

Compatible with spec and previously a feature. I agree that it should be patched but Chrome's policy has historically made local web development and testing a pain in the ass because now you have to configure a web server correctly and work around Chrome's broken cache-control policy (have fun ctrl-f5'ing all the time or opening devtools to disable cache, which deoptimizes your JS) I struggled with this for years and opened multiple bugs about it. If you're trying to release software to end-users that requires them to configure a whole damn web server you get really tired of it. Disabling content loading from file:// is one solution, but I feel like the 'this was loaded from the internet' flag already used for downloaded EXEs and DLLs is a perfectly reasonable alternative that would work just as well without breaking things for local development. (To be clear, you don't offer the option to bypass that, since it would only be a security vulnerability)

ChrisSD 7y ago
Does`python -m http.server 8000` not work for local development?
- kevingadd 7y ago
  You need way more configuration than that, python's http server doesn't handle keepalive and threading correctly (or didn't when I last used it, maybe that's fixed in 3). I historically had to use IIS or Apache, and at work we used a full Apache install. If you used python your performance was much worse if your application worked at all. For C# apps you can at least just spin up a HTTPD directly in your app using system APIs, but it's also kind of flaky.
  - ChrisSD 7y ago
    I'm just surprised that file:// works better (when it's allowed).
    - kevingadd 7y ago
      It was very fast, at least for a while. It might be slow now.

est31 7y ago

IMO, the approach taken by Chrome and other browsers is over restrictive, basically killing off the file:// protocol. Already now it's impossible to load wasm files in the file:// protocol in Chrome, and I think this also had implications on using wasm in electon. Ultimately, file:// is a great, cloud free method of having web pages and applications and it should stay that way instead of forcing everything to be networked and reliant on third party computers or domain names. There are so many reports, documents, etc that live as non-networked html files. E.g. rust documentation (cargo doc --open) is generated as html files on-disk and then just displayed without the need for a webserver. Starting a localhost webserver is in fact less secure than file because now every user on the computer has access instead of just the users with read-access to the files. This has thankfully been fixed in Chrome OS though. Responsive web apps are not the solution as they still need "seeding" via the network. Maybe some kind of standardized format where you have a glorified zip file with some metadata and when you double click it, it opens in the web browser which starts a web server in the background that runs a specially designated js in that zip file and which can accept usual fetch requests and has read access to the entire zip file. The browser's "UI" would then communicate with the server via well-known protocols.

kevingadd 7y ago
It ends up definitely being a tax on developer efficiency overall. It also makes web development more hostile to newbies because they have to figure out how to configure a server or hop into some third-party toolset on the web to start experimenting. With the tendency to ban use of new features on non-HTTPS origins (hi again, Chrome) a newbie developer will soon have to have both a server and a https cert before they can even start experimenting. If they host on a third-party https domain now third parties are responsible for malware that might get hosted there. It just sucks.
- codedokode 7y ago
  Regarding HTTPS, localhost is considered a "secure" origin: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts#When_is_a_context_considered_secure https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

techntoke 7y ago

Mozilla's latest tactic appears to be to trash Chrome semi-weekly on HN and then try to bring in users to Firefox. Then, later that week a new vulnerability is discovered in Firefox.

dang 7y ago
This breaks the site guidelines by being flamebait, by insinuating astroturfing, and by using HN threads to fight some sort of pre-existing battle. You've done this before, and we've had to warn you before. If you keep doing it we're going to have to ban you, so please stop. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

garaetjjte 7y ago

Killing javascript access to file:// would be annoying for quick experimenting. Maybe denying network access to locally loaded JS, so that nothing could be transferred out is possible solution?

tomatsu 7y ago
You need to spin up a server if you want to use modules anyways. Well, it's not a big deal. Just run `python3 -m http.server` or install "http-server" via npm.
- ajsnigrutin 7y ago
  This is not something a kid learning basic html/js can do easily, since he probably uses windows, and doesn't even know how to navigate in the command prompt. The "click on the html file on the desktop" just works(TM)

deleted 7y ago

[deleted]

jasonhansel 7y ago

Can we at least disallow iframes containing file:// URIs? Essentially treat them as if they had X-Frame-Option: DENY.

usr1106 7y ago

I am not a Web programmer, so what I suggest might be nonsense. Please correct constructively :) The central statement seems to be: > “Our implementation of the Same Origin Policy allows every file:// URL to get access to files in the same folder and subfolders.” What about the following simple mitigations: * Access by file:// URL to the root and user's home directory proper are forbidden by the browser implementation (Because all subdirectories of the home directory is always a bad idea, root even worse so) Hard-coded, error dialog, period, no way to override short of patching the browser or mounting trickeries. * Access to any other subdirectories is allowed, but will cause a warning that by proceeding you grant access to the directory and all it's subdirectories. The warning cannot be suppressed by normal settings, but appears only once a day. An average user will not get it frequently, so there is a chance that they read it (and if they click OK without reading it's their problem). And for the Web developer clicking once per day is still easier than configuring an Apache. And ideally they know why they are clicking it.

Tharkun 7y ago

Another good reason to use Firejail. You tell it which folders FF gets to access, and Bob's your uncle.

OJFord 7y ago
But if this is only leaking the directory you choose to download, Bob's already your uncle? Issue is that people don't and don't want to choose a fresh/clean-enough directory every download.
grapeli23 7y ago
It's easier to create a new user account and run firefox from it. Something like: xhost +si:localuser:firefox && su - firefox -c 'DISPLAY=:0 HOME=/home/firefox firefox 2>/dev/null' && xhost -
- Tharkun 7y ago
  Yeah, because that's a lot easier than just running "firejail firefox".. And does your snippet work on Wayland?

cesnja 7y ago

To avoid this, I use Firejail [1] with a custom rule set to limit the browser's access only to Downloads and its own profile folder. Does anybody know of anything similar for MacOS? [1] https://firejail.wordpress.com/ https://firejail.wordpress.com/

Liquid_Fire 7y ago
From the article, access is already limited to the directory in which the HTML file is located, so this wouldn't help. Either it would be in the Downloads directory, where it already has access, or it would be in another directory and you wouldn't be able to open the file at all unless you disable your sandbox.

mmis1000 7y ago

So, what is it different to download random exe and execute it? Isn't that accessible by design as the dir html allocated is also the root path of that page? Beside that, aren't both windows and macos warn you when you open random file downloaded from internet?