
Firefox Local Files Theft – Not Patched Yet - akeck
https://quitten.github.io/Firefox/
======
est31
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.

~~~
mort96
Learning web programming is amazing, since you can just start writing a .html
file and open it in a browser. There is no need to learn how go set up a local
http server. Chrome truly is killing that experience; you can't even load
javascript modules without http involved now outside of Firefox.

I really hope Mozilla doesn't "fix" this "vulnerability" by destroying the
experience of people learning web programming like Google did.

~~~
majewsky
Is it really that hard to run `python -m http.server` in your repository?

~~~
adrianN
When I was about 13 I wanted to learn C++. I bought a book, installed the
software from the CD and tried compiling the first example. It failed with a
cryptic error about a file not being found. I gave up on programming for a
number of years.

The book had failed to mention that I need to include the compiler in my PATH.

~~~
kspp
Honestly, if that's all that took you to give up on programming, it would not
have gone on much longer anyway, especially with something like C++.

~~~
adrianN
So what was I supposed to do with no expert on hand and no Internet? I went
back to the bookshop and asked there. They didn't know either, so I returned
the book.

I returned to programming when I learned about Quickbasic. That just worked
and had an extensive help system that was suitable for self study.

------
ChrisSD
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
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
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
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
Because they already have the run of the user's profile. Why add additional
complexity for less access?

~~~
Tiki
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
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

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

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

------
kevingadd
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
Does`python -m http.server 8000` not work for local development?

~~~
kevingadd
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
I'm just surprised that file:// works better (when it's allowed).

~~~
kevingadd
It was very fast, at least for a while. It might be slow now.

------
garaetjjte
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
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
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)

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

------
usr1106
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
Another good reason to use Firejail. You tell it which folders FF gets to
access, and Bob's your uncle.

~~~
grapeli23
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
Yeah, because that's a lot easier than just running "firejail firefox".. And
does your snippet work on Wayland?

------
cesnja
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
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
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?

------
techntoke
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
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)

