Closed Bug 424297 Opened 15 years ago Closed 5 years ago

Information Leak: default browser settings

Categories

(Firefox :: Security, defect)

x86
Windows Server 2003
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 863246

People

(Reporter: michael16, Unassigned)

References

()

Details

(Keywords: sec-other, Whiteboard: [sg:nse])

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.
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/>
Summary: Remote execution exploit leaves many users vulnerable. → Information Leak: default browser settings
Group: security
Severity: critical → normal
Whiteboard: [sg:nse]
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
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?
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.
Not exactly a duplicate (more of a subset), but this will be fixed by bug 863246
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 863246
You need to log in before you can comment on or make changes to this bug.