Last Comment Bug 568148 - (CVE-2010-1213) Combining "importScripts" of WebWorker with E4X causes information disclosure
(CVE-2010-1213)
: Combining "importScripts" of WebWorker with E4X causes information disclosure
Status: RESOLVED FIXED
[sg:high] fixed-in-tracemonkey [crits...
: verified1.9.1, verified1.9.2
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
: P1 major (vote)
: mozilla1.9.3a5
Assigned To: Brendan Eich [:brendan]
:
: Jason Orendorff [:jorendorff]
Mentors:
http://openmya.hacker.jp/hasegawa/PoC...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-25 20:03 PDT by Yosuke HASEGAWA
Modified: 2014-10-12 13:20 PDT (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
.7+
.7-fixed
.11+
.11-fixed


Attachments
fix, always reject only-XML JS source whether script result wanted or not (755 bytes, patch)
2010-05-25 20:43 PDT, Brendan Eich [:brendan]
gal: review+
Details | Diff | Splinter Review
followup fix (737 bytes, patch)
2010-05-27 14:25 PDT, Brendan Eich [:brendan]
brendan: review+
Details | Diff | Splinter Review

Description Yosuke HASEGAWA 2010-05-25 20:03:42 PDT
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] 2010-05-25 20:43:19 PDT
Created attachment 447465 [details] [diff] [review]
fix, always reject only-XML JS source whether script result wanted or not
Comment 2 Brendan Eich [:brendan] 2010-05-25 20:44:01 PDT
Reporter, thanks for finding this!

/be
Comment 3 Andreas Gal :gal 2010-05-25 20:50:01 PDT
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] 2010-05-25 20:51:08 PDT
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 2010-05-26 22:39:04 PDT
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] 2010-05-26 23:03:10 PDT
(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] 2010-05-27 14:25:12 PDT
Created attachment 447835 [details] [diff] [review]
followup fix

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

/be
Comment 8 Brendan Eich [:brendan] 2010-05-27 14:39:57 PDT
Followup fix:

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

/be
Comment 9 Daniel Veditz [:dveditz] 2010-06-02 10:59:28 PDT
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] 2010-06-02 15:03:03 PDT
Cc'ing jorendorff re: comment 9 question -- we have workers in the js shell, IIRC.

/be
Comment 12 Brendan Eich [:brendan] 2010-06-18 14:29:32 PDT
Comment on attachment 447835 [details] [diff] [review]
followup fix

This went in.

/be
Comment 14 Al Billings [:abillings] 2010-06-22 17:42:51 PDT
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] 2010-06-25 15:01:02 PDT
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 christian 2010-06-30 21:19:47 PDT
Yep, off lists.
Comment 17 Joshua Mitchell (Inactive) 2014-10-12 13:20:51 PDT
Issue is resolved - clearing old keywords - qa-wanted clean-up

Note You need to log in before you can comment on or make changes to this bug.