568148 - (CVE-2010-1213) Combining "importScripts" of WebWorker with E4X causes information disclosure

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Yosuke HASEGAWA]

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">

Comment 1

[Brendan Eich [:brendan]]

Attachment: fix, always reject only-XML JS source whether script result wanted or not

Comment 2

[Brendan Eich [:brendan]]

Reporter, thanks for finding this!

/be

Comment 3

[Andreas Gal :gal]

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.

Comment 4

[Brendan Eich [:brendan]]

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

Comment 5

[Jesse Ruderman]

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.

Comment 6

[Brendan Eich [:brendan]]

(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

Comment 7

[Brendan Eich [:brendan]]

Attachment: followup fix

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

/be

Comment 8

[Brendan Eich [:brendan]]

Followup fix:

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

/be

Comment 9

[Daniel Veditz [:dveditz]]

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?

Comment 10

[Brendan Eich [:brendan]]

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

/be

Comment 11

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/d5c0c147d6f0

Comment 12

[Brendan Eich [:brendan]]

Comment on attachment 447835 [details] [diff] [review]
followup fix

This went in.

/be

Comment 13

[Brendan Eich [:brendan]]

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

/be

Comment 14

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 15

[Brendan Eich [:brendan]]

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

[LegNeato]

Yep, off lists.

Comment 17

[Joshua Mitchell (Inactive)]

Issue is resolved - clearing old keywords - qa-wanted clean-up