Bug 568148 (CVE-2010-1213)

Combining "importScripts" of WebWorker with E4X causes information disclosure

RESOLVED FIXED in mozilla1.9.3a5

Status

()

Core
JavaScript Engine
P1
major
RESOLVED FIXED
7 years ago
3 years ago

People

(Reporter: Yosuke HASEGAWA, Assigned: brendan)

Tracking

({verified1.9.1, verified1.9.2})

unspecified
mozilla1.9.3a5
verified1.9.1, verified1.9.2
Points:
---

Firefox Tracking Flags

(blocking1.9.2 .7+, status1.9.2 .7-fixed, blocking1.9.1 .11+, status1.9.1 .11-fixed)

Details

(Whiteboard: [sg:high] fixed-in-tracemonkey [critsmash-high:patch], URL)

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)

"importScripts" method reads remote resources as a javascript even if that is not a JavaScript file. 
And "importScripts" method sent cookies to remote server at requesting their resources.
Additionally, "importScripts" method can read HTML file as JavaScript source using E4X feature.
Thus attacker can read the victim's protected HTML file using "importScripts" and E4X across the domain.

Reproducible: Always

Steps to Reproduce:
see demo page for details.
http://openmya.hacker.jp/hasegawa/PoC/webworker.html
Actual Results:  
attacker can read remote contents.

Expected Results:  
"importScripts" should fail to read HTML as a javascript source, like as <script src="html">
(Assignee)

Comment 1

7 years ago
Created attachment 447465 [details] [diff] [review]
fix, always reject only-XML JS source whether script result wanted or not
Assignee: general → brendan
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #447465 - Flags: review?(gal)
(Assignee)

Comment 2

7 years ago
Reporter, thanks for finding this!

/be
Priority: -- → P1
Target Milestone: --- → mozilla1.9.3a5

Comment 3

7 years ago
Comment on attachment 447465 [details] [diff] [review]
fix, always reject only-XML JS source whether script result wanted or not

Brendan explained the historic reason for bypassing the check in case of TCF_NO_SCRIPT_EVAL (if you wanted the value we were hoping you know what you are doing), but it seems best to always apply it.
Attachment #447465 - Flags: review?(gal) → review+
(Assignee)

Comment 4

7 years ago
http://hg.mozilla.org/tracemonkey/rev/d5c0c147d6f0

JS folks offer to review any JS API based new code, including workers. Seems like a good idea, may not catch everything -- could help improve docs and API at least though (at best it might catch bugs like this).

/be
Whiteboard: fixed-in-tracemonkey

Comment 5

7 years ago
Interesting that even though this patch builds on the fix for bug 375250, it is more severe, because bug 375250 was not exploitable as reported.
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
Whiteboard: fixed-in-tracemonkey → [sg:high] fixed-in-tracemonkey
(Assignee)

Comment 6

7 years ago
(In reply to comment #5)
> Interesting that even though this patch builds on the fix for bug 375250, it is
> more severe, because bug 375250 was not exploitable as reported.

This bug is about a new API, not around when that bug was fixed.

/be
(Assignee)

Comment 7

7 years ago
Created attachment 447835 [details] [diff] [review]
followup fix

Sorry I missed the orange -- thanks to Waldo for pointing it out today.

/be
Attachment #447835 - Flags: review?(gal)
(Assignee)

Comment 8

7 years ago
Followup fix:

http://hg.mozilla.org/tracemonkey/rev/4e04e69a5d41

/be

Updated

7 years ago
Whiteboard: [sg:high] fixed-in-tracemonkey → [sg:high] fixed-in-tracemonkey [critsmash-high:patch]
status1.9.1: --- → wanted
status1.9.2: --- → wanted
qawanted: please turn the test link into an attachment to this bug so we know we'll have it for regression testing.

brendan: could we turn the testcase into something we could check-in once the fix is public?
blocking1.9.1: ? → .11+
blocking1.9.2: ? → .5+
Keywords: qawanted
(Assignee)

Comment 10

7 years ago
Cc'ing jorendorff re: comment 9 question -- we have workers in the js shell, IIRC.

/be

Comment 11

7 years ago
http://hg.mozilla.org/mozilla-central/rev/d5c0c147d6f0
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
blocking1.9.2: .5+ → .6+
(Assignee)

Comment 12

7 years ago
Comment on attachment 447835 [details] [diff] [review]
followup fix

This went in.

/be
Attachment #447835 - Flags: review?(gal) → review+
(Assignee)

Comment 13

7 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a705562554f8
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d4b2224cf458

/be
status1.9.1: wanted → .11-fixed
status1.9.2: wanted → .6-fixed
Verified for 1.9.1 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11pre) Gecko/20100622 Shiretoko/3.5.11pre ( .NET CLR 3.5.30729) using testcase. Checked in build before checkin and testcase reproduced bug there. 

Verified for 1.9.2 the same way in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6pre) Gecko/20100622 Namoroka/3.6.6pre ( .NET CLR 3.5.30729) and the build from the day before the fix.
Keywords: verified1.9.1, verified1.9.2
(Assignee)

Comment 15

7 years ago
I didn't attach a patch here, but it was a one-liner. See comment 13. Can I get off the list of bugs without approved patches without actually attaching a patch and getting (retroactive) approval?

/be

Comment 16

7 years ago
Yep, off lists.
Alias: CVE-2010-1213
Group: core-security
Issue is resolved - clearing old keywords - qa-wanted clean-up
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.