Bugzilla@Mozilla – Bug 568148
Combining "importScripts" of WebWorker with E4X causes information disclosure
Last modified: 2010-09-03 20:23:29 PDT
Summon comment box
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">
Created attachment 447465 [details] [review] fix, always reject only-XML JS source whether script result wanted or not
Reporter, thanks for finding this! /be
Comment on attachment 447465 [details] [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.
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
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.
(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
Created attachment 447835 [details] [review] followup fix Sorry I missed the orange -- thanks to Waldo for pointing it out today. /be
Followup fix: http://hg.mozilla.org/tracemonkey/rev/4e04e69a5d41 /be
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?
Cc'ing jorendorff re: comment 9 question -- we have workers in the js shell, IIRC. /be
http://hg.mozilla.org/mozilla-central/rev/d5c0c147d6f0
Comment on attachment 447835 [details] [review] followup fix This went in. /be
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a705562554f8 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d4b2224cf458 /be
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.
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
Yep, off lists.