827193 - (CVE-2013-0774) disclosure of profile directory name in JavaScript variable visible to Workers

Status: RESOLVED FIXED

(Core :: DOM: Workers, defect)

Description

[Frederik Braun [:freddy]]

Attachment: PoC html file

The variable "OS" in a Web Workers scope contains some peculiar information, among them:

OS['Constants']['Path']['profileDir'], which is the full path to the firefox profile directory, e.g. "/home/freddy/.mozilla/firefox/6efxvygfz.default". 

I know that the path name contains these random characters for security reasons. Although a quick search revealed no easy way to turn this path disclosure into a serious exploit I suppose it still poses a security risk.

If this is wrong, please uncheck the security-confidential flag.

I will attach a simple test case that explains the issue.

Comment 1

[Frederik Braun [:freddy]]

Attachment: PoC JS file

Comment 2

[Frederik Braun [:freddy]]

The PoC HTMl file references the JS file which as to be in the same directory. Hence, this PoC doesn't work on bugzilla but has to be downloaded.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

This seems to have been introduced by http://hg.mozilla.org/mozilla-central/rev/1bbc0b65dffb#l39.1.

"fix build warnings"? o_O

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Sorry, I misread that. http://hg.mozilla.org/mozilla-central/diff/685e5580a1f4/dom/workers/WorkerScope.cpp just put the parenthesis at the wrong place.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch

Comment 6

[:Gavin Sharp [email: [e-mail]]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e370fc6fae8e

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 698518 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): present since introduction of the feature in Firefox 15 (bug 739740)
User impact if declined: privacy leak, potential security risk if combined with other bugs
Testing completed (on m-c, etc.): none
Risk to taking this patch (and alternatives if risky): it's a simple change of logic to match what was originally intended, very low risk
String or UUID changes made by this patch: none

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 698518 [details] [diff] [review]
patch

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: I think the privacy impact/risk ratio is high enough that this merits landing on ESR for the next release as well.

See comment 7 for the rest of the risk analysis.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 698518 [details] [diff] [review]
patch

This impacts b2g as well, but I'm not confident about what the current b2g18 policy is.

Comment 10

[Alex Keybl [:akeybl]]

Comment on attachment 698518 [details] [diff] [review]
patch

Let's wait until after 1/15 to land on B2G's branch.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

https://hg.mozilla.org/releases/mozilla-esr17/rev/bc1851ce7691
https://hg.mozilla.org/releases/mozilla-beta/rev/9461ce8b252a
https://hg.mozilla.org/releases/mozilla-aurora/rev/1903a40f342d

Comment 12

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/e370fc6fae8e

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

Still waiting to take patches for 1.0.1 as per https://wiki.mozilla.org/Release_Management/B2G_Landing we'll be opening mozilla-b2g18 up for landings after 1/25 so leaving the nomination.

Comment 14

[Alex Keybl [:akeybl]]

Comment on attachment 698518 [details] [diff] [review]
patch

This can now be landed mozilla-b2g18, which is currently v1.0.1.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/e34522d63693