so.. this is the standard thing about all file:/// uris being considered part of the same security context. Jesse has existing bugs on this, as I recall.
Dup of bug 230606?
At least dependent.
Depends on: 230606
*** Bug 273502 has been marked as a duplicate of this bug. ***
The problem is that Mozila use the mime-type for served by http documents but it does use the extension for opening local files. Disable the "open with" option if the application is Mozilla itself. This would move the "who is to blame" around to the user because he has to go through the OS Filemanager to open it.
> The problem is that Mozila use the mime-type for served by http documents but > it does use the extension for opening local files. I don't understand. > Disable the "open with" option if the application is Mozilla itself. That wouldn't help much. The default application for .html be another web browser. > This would move the "who is to blame" around to the user because he has to go > through the OS Filemanager to open it. I disagree. I would not blame a user for not knowing that opening an untrusted local .html is dangerous. It should not be dangerous -- that's why I filed bug 230606.
A simple workaround would be to act like Internet Explorer SP2. Disallow scripting and applets in what they call "the local machine" zone. For instance, if a page on the local computer tries to run a script, display a dialog box like ------------------Security Warning----------------- | The file you are trying to view contains active | | content who could read the contents of files on | | your computer. | | | | You should only allow this content to run if | | trust the author of the file. | | | | [ ] Never ask me again. | | | | [Allow] [Deny] | ---------------------------------------------------
Internet Explorer SP2 makes it difficult to develop web pages locally, even when the page is entirely self-contained, because it disables scripts entirely. Furthermore, enabling scripts in a local page gives them abilities they should not have. It would be better to restrict the same-origin policy for local files. If that causes problems for many web developers (I don't think it will), Firefox can show a warning similar to IE's if the page tries to violate the new same-origin policy by reading another local file.
> Anyway it cannot be exploited "directly" by a remote site, but only if the > page is opened from a local path Adding that to summary
Summary: Disclosure of local file content in Mozilla Firefox and Opera → Disclosure of local file content to locally opened HTML files
Jesse, imo (may or may not be worthy for this bug) this dialog should only show if someone needs to READ the contents of another local file, via scripting for example as in this bug, or via an IFRAME (perhaps) etc. Simply including/changing a <image> or <object> src itself should not have any blockage on it, if the callee is local system. /me removes any sense of a developer and notes that he has no experience in developing security policies just for the record.
fix would need testing on the trunk. -minus for 1.0.1
Flags: blocking-aviary1.0.1? → blocking-aviary1.0.1-
Mozilla would be free to implement whatever security checks seemed easy or reasonable if most web developers never put absolute URLs in their local HTML in the first place. That would make this bug fix straightforward. Web developers create local files with absolute URLs mostly because they need to test form submission out before they publish their sites. If Mozilla could submit forms locally when the HTML is local and URLs are relative, then web developers could test out their form submission without having to hack absolute URLs into their locally stored files in the first place. That is a sanity increase for web developers. To implement this, have trivial local form-submission support that just logs the form data to a log file and replies with an HTTP 204. More completely, add a config option enabling client-side CGI (bug 68702) through the local ./cgi-bin, or whatever. Enable it only when the origin is local disk. - N.
(In reply to comment #9) > > Anyway it cannot be exploited "directly" by a remote site, but only if the > > page is opened from a local path > > Adding that to summary My target was explain how a remote user could take advantage by some feature for read local file, using a Content-Type "spoofing" to trick the user to open an html page. I think that this could represent a security/privacy problem for the 80% of users. In your opinion how many people would choose "Open" when a dialog window is showed to view an html page? I think at least 80 % ( and maybe more ;) ) Note that i have made some test with several browsers and just with Mozilla Firefox and Opera* has been possible have a successful "exploitation". I think that at least a window with a warning for the user would be usefull. Best Regards, Giovanni Delvecchio.
moving blocking status to beta2, assuming this is still on our important to fix list.
Flags: blocking1.8b+ → blocking1.8b2+
I think we had a big discussion about this somewhere but I can't remember how it ended. Seems to me we could make a huge dent in this problem by doing two things: -- Modify our "Save As" code to emit metadata indicating those HTML files should be in a sandbox. -- Detect when content is on a remote filesystem and sandbox it by filesystem.
I don't think roc's solution is the right one. There are plenty of other ways for .html files to get on the user's hard drive, including: * URLs with "content-disposition: attachment" and an .html extension. * Attachments from e-mail programs other than Thunderbird. * Files sent over AIM. * HTML files included in illegal torrents of music CDs. * Zip archives from the web or from e-mail. As a result, roc's solution would make our message to users *more* complicated than it is now. The current message is "Opening local HTML files is not safe". With roc's change, the message will be "Opening local HTML files is not safe, unless you saved them with Firefox". In contrast, tightening the same-origin policy for local files would eliminate the need for this message. (There could be an information bar if a file attempts to violate the same-origin policy, with UI to override.)
I think roc's point is a very weak security regime, because it allows the user or apps that share user files to compromise Mozilla security merely by specifying the right data. At least other, equivalent attacks (say on user_prefs.js) can be locked out by a network admin. Not so for arbitrarily named files. I've been doing cross browser DHTML testing lately, and have a renewed appreciation of how poorly IE supports web developers, including its information bars for local files. The IE information bar is highly annoying, but I'm too busy analysing micro-iterations of my page to ever spend time getting rid of it permanently. So effectively I'm stuck with it. I observed this behavior in other web developers too. My take-away is that we should resist smacking web developers in the face with bars that they don't want to interact with at all. I also spent some time trying to shoot comment 12 down. All I managed to do was see that "local submits" also support automated testing. The message that local submits gives to users is "Opening local files is safe" - since Jesse's info bar will pop up ifany submit target's a remote website. The message local submits gives to web developers is: "Opening local files 'just works' if you use relative urls". Where's the downside? - N.
I don't understand the third paragraph of Nigel's comment 17. Forcing forms in local pages to "submit locally", whatever that means, wouldn't prevent local pages from using or communicating information about local files in other ways. Fixing the same-origin policy would be easier and would break fewer pages than trying to prevent local pages from communicating information to the outside world.
(local submit means putting a CGI gateway or similar inside Mozilla) I'm not suggesting local submits are a security tactic. My suggestion is about reducing the number of warnings that need to be thrown up IF we improve security. I'm in favour of enforcing "same origin" with a warning dialog box or an information bar at all times. My point is that there's a corner case where we can avoid upsetting developers and still make users safer. It is when you have: a) a HTML file on local disk b) with a form in it c) that submits to a relative URL. Here's an example. Try submitting after loading this /tmp/test.html: <html><body> <form method="get" action="foo.cgi">...<input type="submit"></form> </body></html> Normally this combination throws up an alert if you submit - 'foo.cgi not found'. Now, if you also create a /tmp/foo.cgi, and then submit again, foo.cgi is just returned as plain text without being run thru CGI. Web developers know this, so they replace "foo.cgi" in the page with "http://example.com/foo.cgi", in order to get real CGI. They change a relative URL to an absolute one for the sole reason that they would like to test the local copy of their page. With same-origin enforced for local disk, that will mean an extra warning for web developers, ala IE, since the page and the CGI resource are different origins. That's a security improvement, but no improvement for web developers. In fact it's worse than what they have today. Nevertheless, I support adding this extra warning in this case, for the security reasons cited by this bug. However, if the original "foo.cgi" actually WAS called as a CGI (local submit), then the page and submit are happily all in the same origin (local disk). Web devs wouldn't have to hack in "http://example.com/foo.cgi" in order to test page submission (because local submit works for relative URLs) AND they wouldn't get ANY warning dialog, neither old or new. It's a smoother development experience, with no irritations, and better than today's arrangements. With local submits, end-users still have the better protection afforded by new warnings. If anyone persuades them to save an HTML document to local disk, and then load it, and then submit its form, they either get a warning (absolute URL in form = different orgin), or their data stays local (relative URL in form = local submit). In the local submit case, effectively nothing happens, which is safe. Hope that's clearer. If this suggestion were to be taken up, then X% of the imaginable test cases for a final fix would cause a warning, and the other (100-X)% cases would silently cause local submits in order to support web developers. - N.
IE's solution is here: http://msdn.microsoft.com/workshop/author/dhtml/overview/motw.asp This is the same as the first half of comment #15, and in IE I think this is a poorly thought-out solution. To break it, just catch a virus that scans local .htm files and removes this metadata. IE's security is then blown. If Mozilla relied on metadata, our security would be blown by that virus as well. Better to have security inside the Mozilla binary. The idea of "MOTW" is also a piece of Microsoft marketing rhetoric designed to make the web look unsafe next to Windows. Let's not participate in that. - N.
(In reply to comment #20) > This is the same as the first half of comment #15, and in IE I think > this is a poorly thought-out solution. To break it, just catch a virus > that scans local .htm files and removes this metadata. If there's a virus running on your system, it can already do whatever it wants, including download and run arbitrary code, so I don't understand why this should be considerd a vulnerability in the metadata approach.
roc, you're quite right, but should Mozilla be a domino that falls automatically when the IE domino falls? I think the metadata approach is particularly easy for a script kiddie to exploit. We don't mark the individual resources in other URL schemes with security info, so why should we make an exception for file: when same origin can do the job. Is there a use-case that same-origin doesn't cover? - N.
(In reply to comment #22) > roc, you're quite right, but should Mozilla be a domino that falls > automatically when the IE domino falls? I think the metadata > approach is particularly easy for a script kiddie to exploit. Once an attacker is running arbitrary code on your system, all dominos have fallen. They could, for example, reconfigure Mozilla (or IE) so that all sites are fully trusted. It is futile to try to protect the user from the effects of a full system compromise. [Okay there's still a distinction between "running arbitrary code as user" and "able to run arbitrary code as root/Administrator" but that's not in view here.] > We don't mark the individual resources in other URL schemes with > security info, so why should we make an exception for file: when > same origin can do the job. Is there a use-case that same-origin > doesn't cover? The problem is that we don't have a reasonable same-origin policy for file: sources.
speculated on a solution in n.p.m.security: <email@example.com> - N.
Dan, It's not clear to me that this is something that we need to, or are likely to fix for 1.8b3. Please reset the blocking+ flag if it still is.
*** This bug has been marked as a duplicate of 230606 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.