Firefox Local Files Theft – Not Patched Yet
quitten.github.io
quitten.github.io
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.
It just sucks.
This would allow the convenience of file:// and IMHO eliminate many if not all of the risks.
I’m fine with having a very clear toggle to allow this behavior for developer types, but this should default to secure.
There's a lot of the comments along the lines of "just run python -m SimpleHTTPServer" - but doing that makes your computer just as vulnerable as allowing file:// in the first place, in theory. It's only the very awkwardness of doing that that makes it any safer. Instead of hiding this fundamental incompatibility between security and local accessibility behind a layer of inconvenience, better to drag it out into the open and label it and fully support it. While you're at it, you can slacken off some of the other restrictions in "local mode" as well.
A browser is the modern VM, for better or worse. It should function locally, standalone.
It should not. Electron runtime is not a browser and developer can tweak its security settings.
I would suggest another idea for local files: grant access to folder whose name matches HTML file name, with suffix. For example: file some-page.html and directory some-page_files.
Yes, that's what I meant. Sure you can override chromium, but you have to. https://github.com/adamvoss/electron-webassembly-hello/commi...
> I would suggest another idea for local files: grant access to folder whose name matches HTML file name, with suffix.
That would certainly help. It would restrict some multi-html-file projects a bit though that use shared resources. Probably can be helped by having a folder named html-fetchable-files or something.
I really hope Mozilla doesn't "fix" this "vulnerability" by destroying the experience of people learning web programming like Google did.
Leave the complexity of learning what Python is, the 2 vs 3 issue, 32/64 bit versions, appending locations to your path, CLI, etc., for when the user is ready to start with dynamic web pages.
Edit: Here are 16 for example: https://gist.github.com/willurd/5720255
Even for people on Mac and Linux, having to start by learning the terminal is a pretty big and unnecessary obstacle to just getting to writing some JavaScript. Sure, you and I think it's easy, but it's a completely different paradigm which requires practice to get comfortable with.
Even if you can be there right by someone learning to program, and help them set up a web server, they will have to remember how to do that when they want to play with programming while you're not there. That's actually quite a lot to remember when you don't yet understand what the commands mean; you think of it as "go to the directory, start SimpleHTTPServer", but they have to memorize the text they have to type. Maybe you're the one who cd'd into the correct folder for them, and they remember to type `python -M SimpleHTTPServer` in the terminal you created; they will then have problems they don't know how to solve when they go home and open a terminal and type the command and it doesn't work because they weren't in the correct directory.
On topic, I agree that this is throwing the baby out with the bathwater. A compromise would perhaps be an explicit whitelist of allowed directories to serve via the file:// protocol, set by the user (while disallowing traversal upwards of these, of course).
php -S localhost:3000 -t ./How is that easier than putting file://path/to/foo.html into my browser window, as someone getting started in web development?
Personally, as a person who used python in my programming job, I don't remember when for last time or even I have ever typed mentioned by you command to start a local server.
It (almost, kind of) is now, actually. Running python on a recent Windows 10 box without python installed will prompt you to install it.
https://devblogs.microsoft.com/python/python-in-the-windows-...
The book had failed to mention that I need to include the compiler in my PATH.
I returned to programming when I learned about Quickbasic. That just worked and had an extensive help system that was suitable for self study.
$ busybox httpd -p 8080 -f
-p for port (also possible to bind to specific IP: -p 127.0.0.1:8080), -f for foreground, also optional -h for served directory (default is .).
But the difference between doing almost nothing, a double click once and then it stays there even between restarts, to giving a specific command in a terminal is monstrously huge.
However the barrier of entry is still higher than simply editing a .html file and loading it from the browser with file://
The question is, what is more important? Shouldn't this functionality be optional at the very least?
But in this case, it's much simpler to make a tar or a zip with the HTML and all necessary files. eg. that's how Python "eggs" work.
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.
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.
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.
EDIT: it seems there is some progress on making a Firefox Flatpak: https://bugzilla.mozilla.org/show_bug.cgi?id=1441922
> 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.
<script>
fetch(".").then(r => console.log(r));
fetch("/").then(r => console.log(r));
</script>
TypeError: NetworkError when attempting to fetch resource. test.html:2:1If 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.
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.
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)
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.
Well, it's not a big deal. Just run `python3 -m http.server` or install "http-server" via npm.
The "click on the html file on the desktop" just works(TM)
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.
Issue is that people don't and don't want to choose a fresh/clean-enough directory every download.
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.
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?