424297 - Information Leak: default browser settings

Status: RESOLVED DUPLICATE of bug 863246

(Firefox :: Security, defect)

Description

[admin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

Using the right javascript, a site can get a user's settings and even send malilious payloads. I love Firefox, but this is serious!

Reproducible: Always

Steps to Reproduce:
1. Copy the javascript on the page
2. Play with it
Actual Results:  
The contents of the file are displayed as proof of concept.

Expected Results:  
Not let the remote site see the files.

Comment 1

[Brandon Sterne (:bsterne)]

Updated bug summary to accurately reflect the issue.  There is no remote execution involved with Ronald's PoC nor does it involve sending malicious payloads.

As Shaver and others have pointed out, this PoC allows websites to view default browser settings NOT data from a user's profile directory:
<http://shaver.off.net/diary/2008/02/10/view-sourceresource-vulnerability-does-not-expose-personal-information/>

Comment 2

[Johnathan Nightingale [:johnath]]

Brandon - any reason not to resolve this as INVALID?  There's no risk here that I can see - a person can accomplish the same thing by inspecting our source.

Comment 3

[Daniel Veditz [:dveditz]]

The user may be attempting to disguise which version of Firefox they were using (UA spoofing, for example, and more subtle things done by the TorButton addon). Being able to read the default prefs would reveal that the browser is Firefox and which major version at least.

That's possible in other ways through feature detection. One set that comes to mind: Does the browser support globalStorage (FF2+)? restrict globalStorage to document.location.host (FF3)? support localStorage (FF3.1)?  You could construct a similar set testing JS language features, and others.

Comment 4

[Johnathan Nightingale [:johnath]]

Yeah, I think fixing this bug wouldn't materially hurt the ability of a nasty web site to detect browser version, and I'm not really sure if that problem is even solvable on trunk (as opposed to a very tricky extension that munged user agent, DOM features, faked JS bugs, changed pipelining settings, &c.)

Does that make this bug INVALID because the flaw isn't what it appears to be, or WONTFIX because we're unlikely to change the behaviour that is actually occurring?  Or are you suggesting that we actually want to change this, Dan?

Comment 5

[Daniel Veditz [:dveditz]]

It's not invalid -- you can read things you weren't intended to this way. If we're really not going to change this then maybe WONTFIX, but I can't see any good reason to allow web content <script> tags to source resource: or view-source: URIs. So far I can't think of anything in there that's particular worth reading, but that may change in the future.

Comment 6

[Daniel Veditz [:dveditz]]

Not exactly a duplicate (more of a subset), but this will be fixed by bug 863246