273502 - Too large file:// access

Status: VERIFIED DUPLICATE of bug 273419

(Core :: Security, defect)

Description

[Met - Martin Hassman]

For info:
<http://www.securityfocus.com/archive/1/383147/2004-12-02/2004-12-08/1> maybe
you know already. In answer is written "Attacker can *browse* target's folders
and files(file content, filename, filesize, and even the date)."

He has true (even with the *file content*). It is not problem only it this case
(sending bad MIME type form *.html file), but the fact that scripts launched
from file:// has access to the complete the file:// can lead to more potential
problems.


I have prepared simple "exploit" (see attachment), which started from the
file:// (not from the http://) will browse your disk, tries to found as many
Mozilla/Firefox/Thunderbird profiles as possible and load files with passwords
(big problem if the user isn't using master password). It is Windows-only,
looking for profiles only in the C:\Documents and Settings\* and
C:\WINDOWS\Application Data\* so it isn't working in every case - only for the
demonstration (someone can write more sophisticated example).

Report in the
<http://www.securityfocus.com/archive/1/383147/2004-12-02/2004-12-08/1> is only
1 possible problem how to exploit this. User cannot be sure about starting
*.html files from the CD-ROM, a:\ or \\intranet-computer\share\ because it can
send his passwords (or some other files) to the net!

Solution? Not easy. Nobody want to simply block access for the file://. There
will be intranet applications using this. So only some my ideas:

a) do not allow file:// scripts to access another drive (in similar way like it
is implemented in http:// domain security). It won't solve all problems, but can
help a little.

b) limit file:// access only to the current directory and subdirectories (do not
allow script from file:///C:/temp/ read file:///C:/ ). It is better, may be can
break some intranet applications, but not every. It the user can switch it off
in about:config, seems almost OK for me.

c) or do not limit file:// access, but *strictly* warn users every time when the
file:// is trying to access http:// (so script can find data, but cannot send them).

Comment 1

[Met - Martin Hassman]

Attachment: exploit example - windows only (start it from file://)

Comment 2

[Boris Zbarsky [:bzbarsky]]

> c) or do not limit file:// access, but *strictly* warn users every time when
> the file:// is trying to access http:// (so script can find data, but cannot
> send them).

This is really not an option -- it's common for web pages at file:// to load
images, etc over http://, and it's trivial to send data in the URI...


*** This bug has been marked as a duplicate of 273419 ***