Closed Bug 1441468 (CVE-2019-17000) Opened 6 years ago Closed 5 years ago

csp bypass using object tag

Categories

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

Product:
Core
Component:
DOM: Security
Version:
58 Branch
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla70
Tracking Flags:
Tracking Status
firefox-esr60 --- wontfix
firefox-esr68 - wontfix
firefox67 --- wontfix
firefox68 --- unaffected
firefox69 --- wontfix
firefox70 --- fixed
firefox71 --- verified
firefox72 --- fixed
firefox73 --- verified

People

(Reporter: yangzheng.li, Assigned: ckerschb)

References

Details

(Keywords: sec-moderate, Whiteboard: [fixed by bug 1555043][adv-main70+][post-critsmash-triage]) 

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

Steps to reproduce:

visit this POC.html:
===
<html>
<meta http-equiv="Content-Security-Policy" content="default-src 'self';script-src 'none';object-src data:;img-src 'none';frame-src data:"/>
<!-- CSP is set and both script-src and img-src is 'none' -->
<body>

<!-- inline script will run and remote image load -->
<object data='data:text/html;,<svg version="1.1" width="660" height="342" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><script>console.log("Remote Image test")</script><image xlink:href="https://ss0.bdstatic.com/5aV1bjqh_Q23odCf/static/superman/img/logo/bd_logo1_31bdc765.png?x" width="660" height="342"/></svg>'></object>


<!-- CSP works fine -->
<iframe src='data:text/html;,<script>console.log("Remote Image test")</script><img src="https://ss0.bdstatic.com/5aV1bjqh_Q23odCf/static/superman/img/logo/bd_logo1_31bdc765.png?x" width="660" height="342"/>'></iframe>
</body>
</html>
===


Actual results:

in object tag , inline script runs and remote image loads , but in iframe tag ,CSP works fine


Expected results:

Ref: https://www.w3.org/TR/CSP3/#directive-img-src
"This directive controls requests which load images. More formally, this includes requests whose type is "image" [FETCH]."

Ref: https://www.w3.org/TR/CSP3/#directive-script-src
"The script-src directive restricts the locations from which scripts may be executed. This includes not only URLs loaded directly into script elements, but also things like inline script blocks and XSLT stylesheets [XSLT] which can trigger script execution."

object tag should behaves like iframe
Christoph, let me know if I should ping someone else for these CSP issues.
Flags: needinfo?(ckerschb)
Group: firefox-core-security → dom-core-security
Component: Untriaged → DOM: Security
Product: Firefox → Core
This seems like a duplicate of Bug 1441096 to me. We don't inherit the CSP in that case which causes the CSP bypass. I don't know what we do special for object in that case though. Either way, I am pretty sure Bug 965637 will fix the issue within this bug as well as Bug 1441096.
Flags: needinfo?(ckerschb)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: sec-moderate
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]

I don't know which bug fixed this, but this doesn't work in Firefox 70.
Can you help me track down which one it was?

Flags: needinfo?(ckerschb)
See Also: → CVE-2019-17001

(In reply to Frederik Braun [:freddyb] from comment #4)

I don't know which bug fixed this, but this doesn't work in Firefox 70.
Can you help me track down which one it was?

Within Bug 965637 we moved the CSP from the Principal into the Client, but it was Bug 1555043 after all that fixed the problem.

Flags: needinfo?(ckerschb)
Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox69: --- → wontfix
status-firefox70: --- → fixed
status-firefox71: --- → fixed
status-firefox-esr68: --- → affected
Depends on: 1555043, 965637
Resolution: --- → FIXED
Whiteboard: [domsecurity-backlog1] → [fixed by bug 1555043]

Is there anything we can do to mitigate this on ESR68?

Assignee: nobody → ckerschb
Group: dom-core-security → core-security-release
status-firefox67: --- → wontfix
status-firefox68: --- → wontfix
status-firefox-esr60: --- → wontfix
tracking-firefox-esr68: --- → ?
Target Milestone: --- → mozilla70

(In reply to Ryan VanderMeulen [:RyanVM] from comment #6)

Is there anything we can do to mitigate this on ESR68?

This bug is not that bad: we can live with it on ESR68 in my opinion. <object> tags with a data: URL do not inherit the parent's CSP as the spec says it should, but the content is contained in a unique-origin frame. Scripts should have been blocked, but even though they aren't they don't have access to any of the parent window's data (no XSS!). data: URLs have to be explicitly whitelisted in a site's CSP to work and that's not all that common.

We seem to have a slightly worse bug which does inherit the origin and works against a strong CSP of default-src 'none' that we might want to get into ESR 68.

Nevermind. That one is bug 1587976 and does not affect ESR 68.

Whiteboard: [fixed by bug 1555043] → [fixed by bug 1555043][adv-main70+][adv-esr68.2+]
Whiteboard: [fixed by bug 1555043][adv-main70+][adv-esr68.2+] → [fixed by bug 1555043][adv-main70+]
Alias: CVE-2019-17000

Can I ask for a CVE
Credit to Yangzheng Li of Chaitin Tech ?

Thanks a lot.

Flags: qe-verify+
Whiteboard: [fixed by bug 1555043][adv-main70+] → [fixed by bug 1555043][adv-main70+][post-critsmash-triage]

I am attempting to verify the fix of this issue, but I am not sure I understand the actual and expected results. Furthermore, I do not see any difference between the ESR68 v68.2.0esr build and the other builds (Release v70.0.1, Beta v72.0b1 and Nightly v73.0a1). The image is properly loaded on the left scrollable square, but no image is loaded in the right non-scrollable square.
@Christoph : Can you enlighten me so I can properly verify this fix? Thanks!

Flags: needinfo?(ckerschb)

(In reply to Bodea Daniel [:danibodea] from comment #11)

@Christoph : Can you enlighten me so I can properly verify this fix? Thanks!

I think it's best to use this testcase:
https://bugzilla.mozilla.org/show_bug.cgi?id=1587976#c8

(FWIW, I'cced you on Bug 1587976 just in case you didn't have access to it).

Flags: needinfo?(ckerschb)

Using an affected build (Nightly v70.0a1 from 2019-07-15) the test case will show a pop-up with the text "obj-javascript" and then show another pop-up with the text "[JavaScript Application] obj-data".
Using all the other main Firefox versions including ESR v68.3.0esr the pop-up will show the text "[JavaScript Application] obj-data".

The changeset pushed to mozilla-central is not found in the latest ESR build, however, it behaves like the unaffected ones.

Considering the fact that I do not know the actual and expected results, I will need someone to confirm that the verification is valid.
@Christoph: Can you confirm?

Flags: needinfo?(ckerschb)

Freddy, since you also looked at this bug a while ago (comment 4) I was wondering if you have better ways of testing to verify this problem has been fixed - do you?

Flags: needinfo?(ckerschb) → needinfo?(fbraun)

Yeah, this is fixed as danibodea says in comment 13.
There should be no other alert than "obj-data" for a fixed version of Firefox.

Flags: needinfo?(fbraun)
Status: RESOLVED → VERIFIED

Rechecked. Fix verified.

status-firefox68: wontfix → unaffected
status-firefox71: fixed → verified
status-firefox72: --- → fixed
status-firefox73: --- → verified
Flags: qe-verify+
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.