Closed Bug 1456091 Opened 2 years ago Closed 2 years ago

cross-origin info leak by loading simpe text/plain files as <script>

Categories

(Core :: DOM: Security, defect, P3)

59 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1333995

People

(Reporter: ma7h1as.l, Unassigned)

References

Details

(Whiteboard: [domsecurity-backlog3])

Attachments

(1 file)

802 bytes, text/html
Details
Attached file poc.html
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36

Steps to reproduce:

suppose we are attackers from attacker.com , we could steal content of a scretfile in user's site, such as http://www.infelphira.cn/static/secret.txt ,by using error message

this skill is similar to chrome  issue 
https://bugs.chromium.org/p/chromium/issues/detail?id=396544
and  https://bugs.chromium.org/p/chromium/issues/detail?id=667079
but as a matter of fact it's a little different from them

they could only guess the secret javascript variable
but my poc could works against a normal file


Actual results:

attacker recv the content of user's secretkey, and could gain privileges


Expected results:

attacker should not get the content of secretfile
i also report this to chrome and they say there is a same issue 
https://bugs.chromium.org/p/chromium/issues/detail?id=764010
so that i think it would be fine if firefox could also fix it
Group: firefox-core-security → dom-core-security
Component: Untriaged → DOM: Security
Flags: needinfo?(dveditz)
Product: Firefox → Core
This is a known issue, mostly mitigated by the fact that the included file must be valid JavaScript syntax (see bug 471020 comment 41). In practice people probably aren't creating a file that's a single bare word, but some configuration-type files might be parseable. The historical behavior for <script> allowed the inclusion of any type of file which led to more widespread problems (see bug 1048535 comment 2). We tightened up the requirements for Content-Type on script in bug 1288361 and bug 1299267 to prevent loading obviously bad types, but a small number of broken sites led us to continue loading text/plain since that's an ancient default content type some people have used.

Telemetry at https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&keys=__none__!__none__!__none__&max_channel_version=beta%252F60&measure=SCRIPT_BLOCK_INCORRECT_MIME_2&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2018-03-12&table=0&trim=1&use_submission_date=0

Sites can use the header "X-Content-Type-Options: nosniff" on such configuration files to opt-in to stricter MIME type checking on configuration files such as these.

Tom: Do we have a bug to follow up on the telemetry and eventually block text/plain as a valid <script> type? The numbers look fairly low (0.23%) but higher than we usually like to see before removing features that might break sites.

Bug doesn't need to be hidden, this trick is public knowledge.
Group: dom-core-security
Flags: needinfo?(dveditz) → needinfo?(evilpies)
Summary: same origin bypass (info leak) in firefox → cross-origin info leak by loading simpe text/plain files as <script>
No, we don't have a follow up bug for this. I am skeptical about blocking text/plain, especially when unknown is still quite high anyway. "CORB" (https://github.com/whatwg/fetch/issues/681) is coming, which from my understanding would not actually block this, but is at least related.
Flags: needinfo?(evilpies)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Whiteboard: [domsecurity-backlog3]
Actually I just found bug 1333995.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1333995
You need to log in before you can comment on or make changes to this bug.