Cross-origin data leakage through importScripts()

RESOLVED DUPLICATE of bug 1160890

Status

()

defect
RESOLVED DUPLICATE of bug 1160890
4 years ago
3 years ago

People

(Reporter: sdna.muneaki.nishimura, Assigned: baku)

Tracking

({csectype-sop, sec-moderate})

42 Branch
Points:
---
Bug Flags:
sec-bounty -

Firefox Tracking Flags

(firefox40 wontfix, firefox41 affected, firefox42- affected, firefox43 affected, firefox-esr38 affected)

Details

Reporter

Description

4 years ago
Step to reproduce:
1) Launch https://mallory.csrf.jp/importscripts/
2) If "token_1234" is shown in console the flaw is reproduced.

In above page, the document runs a Worker and the Worker loads a cross-origin text data as a script file through importScripts().
But the text data is not a valid script so Firefox fires ReferrenceError.

Then, the error message contains some fragments of the text and the Worker can get the data with try-catch.
In above example the ReferrenceError message contains "token_1234", as shown below, that is loaded from the other origin.

ReferenceError: token_1234 is not defined
Reporter

Comment 1

4 years ago
The similar bug seems to be fixed yesterday by the following commit for mozilla-central.
http://hg.mozilla.org/mozilla-central/rev/37c0bb092ec2

If the patch has already been included in the latest Nightly the patch may not be enough to fix.
Flags: sec-bounty?
Assignee

Comment 2

4 years ago
I think from a spec point of view this is OK.
Flags: needinfo?(bugs)
What do we do on main thread?
Reporter

Comment 4

4 years ago
The following is a document that loads same cross-origin text with <script> on the main thread. 
https://mallory.csrf.jp/importscripts/script.html

The same error message "ReferenceError: token_1234..." is shown on the console but it's log type is "JS",
so any user scripts on the document cannot retrieve this message.

However in case of importScripts the same message is set to an exception object and it can be retrieved by user scripts through catch clause.

Updated

4 years ago
Group: core-security → dom-core-security
IIRC, baku discussed about this with bz, and there were some spec bugs, right?
Flags: needinfo?(bugs) → needinfo?(amarchesini)
(In reply to Muneaki Nishimura from comment #1)
> The similar bug seems to be fixed yesterday by the following commit for
> mozilla-central.
> http://hg.mozilla.org/mozilla-central/rev/37c0bb092ec2

That patch was incorrect and did not fix the bug it was intended to fix.
Assignee

Comment 7

4 years ago
bug 1160890 fixes this issue as well. But I want to write a test before closing this as duplicate.
Assignee: nobody → amarchesini
Flags: needinfo?(amarchesini)
OK, Untracking this bug as we are already tracking bug 1160890
Assignee

Comment 9

4 years ago
This bug is not exactly a duplicate of bug 1160890, but the patch proposed for the first bug fixes this one too.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: CVE-2015-7215
Flags: sec-bounty? → sec-bounty-
Group: dom-core-security
You need to log in before you can comment on or make changes to this bug.