Page MenuHomePhabricator

CVE-2024-23171: Various i18n-based XSSs in Special:EventDetails
Closed, ResolvedPublicSecurity

Description

In Special:EventDetails, there are a bunch of i18n-based XSSs reproducible via the x-xss language. To reproduce,

To reproduce:

  1. First, you need to choose the right wiki. The easiest way is to do this locally, enabling the x-xss language setting in your LS.php. Else you can use the beta cluster, but you will have to add HTML to the messages mentioned below for the XSS to show.
  2. Then, you will first need to create an event:
    1. Make sure you're logged-in
    2. Create a page in the Event: namespace
    3. In the popup that appears post-save, click "Enable registration"
    4. Fill out the form (just the dates are required), submit.
    5. Click the link to go back to the event page
    6. Now you need to register for the event as a participant. Ideally, you need to do this with at least 3 different accounts. When you open the event page as a non-organizer, you will find a "Register for event" button to do that.
  3. Once you have an event with at least 3 participants, click the "manage event" button in the event page (or go to Special:EventDetails/X where X is the ID of your event, if you know it)
  4. Switch to the "Participants" tab

Once you're there, there are a bunch of XSSs you can reproduce in different ways.

  1. Click the checkbox in the table header. You will see an alert from the campaignevents-email-participants-all message.
  2. Then, individually unselect 2 of the participants. You will see another alert from the campaignevents-email-participants-except-count message.
  3. Then, deselect everyone and individually select 2 participants. You'll get another alert from the campaignevents-email-participants-count message.

The root cause of these is the same: the code in question uses .append() instead of .text().

Note that this code is relatively recent (r936290, r944928), only included in wmf.41 branches, and only enabled in a few wikis (see wmgUseCampaignEvents).

Event Timeline

Restricted Application added a subscriber: Aklapper. ยท View Herald TranscriptOct 6 2023, 6:09 PM

@sbassett Even though the code is recent, not enabled in many wikis etc., I assume we may not want to fix this in gerrit, so here's the patch:

sbassett added a project: SecTeam-Processed.

@sbassett Even though the code is recent, not enabled in many wikis etc., I assume we may not want to fix this in gerrit, so here's the patch:

Yep, that's always the safest bet, even if we sometimes handle these message issues publicly. We can likely get this deployed during next Monday's (2023-10-09) security deployment window. CR+2 to the patch, by the way.

We can likely get this deployed during next Monday's (2023-10-09) security deployment window.

Thanks! I'll be available on IRC as usual if you need anything.

@sbassett I think this didn't make last Monday's window. Could it be done today? I'll be around if needed.

@sbassett I think this didn't make last Monday's window. Could it be done today? I'll be around if needed.

Yes, due to the US holiday. @Mstyles or I will try to get this out today for sure.

@sbassett Even though the code is recent, not enabled in many wikis etc., I assume we may not want to fix this in gerrit, so here's the patch:

deployed

The public fix will come out mid December when we do the supplemental release @Daimona

The public fix will come out mid December when we do the supplemental release @Daimona

Is this the process to apply in this case, given that the vulnerable code is in master only? And also in REL1_41, but that's still beta, and not a release yet.

@Daimona the code will be applied to master and then 1.41 when that's released at the end of this quarter

Is this the process to apply in this case, given that the vulnerable code is in master only? And also in REL1_41, but that's still beta, and not a release yet.

Since ext:CampaignEvents isn't bundled with the core release, this issue could theoretically be disclosed and backported at any time, now that a fix is in Wikimedia production. The supplemental security release, released at the end of each quarter by the Security-Team, is more of a catch-all, as it will disclose anything that hasn't been disclosed or re-announce an issue if it has already been disclosed.

Yeah, I guess my point was: the vulnerable code was introduced recently, and no MW release is affected. Only 1.41 will be affected, if the fix is not pushed and backported before the release date (which I believe will be in November). But then again, given that 1.41 has not been released yet, I thought in this case we could make the fix in master and backport it to REL1_41, so that it would be included in 1.41.0.

As you said, this maybe doesn't make much sense given that the extension isn't in the tarball. But OTOH, REL1_41 of the extension should only work with MW 1.41, and because that's still not a thing, nobody should be using REL1_41 just yet.

At any rate, it doesn't really make much difference, except for the (small?) overhead of tracking an additional security patch applied in production. I just thought this could've gone through a simpler process.

At any rate, it doesn't really make much difference, except for the (small?) overhead of tracking an additional security patch applied in production. I just thought this could've gone through a simpler process.

Sure. It's completely fine to make this task public now if that's what you and/or other CampaignEvents developers would like to do. And then send a change set up to gerrit for master and any other relevant branches.

At any rate, it doesn't really make much difference, except for the (small?) overhead of tracking an additional security patch applied in production. I just thought this could've gone through a simpler process.

Sure. It's completely fine to make this task public now if that's what you and/or other CampaignEvents developers would like to do. And then send a change set up to gerrit for master and any other relevant branches.

I think it should be fairly safe to do so, but would like to hear from @cmelo @MHorsey-WMF @VPuffetMichel.

At any rate, it doesn't really make much difference, except for the (small?) overhead of tracking an additional security patch applied in production. I just thought this could've gone through a simpler process.

Sure. It's completely fine to make this task public now if that's what you and/or other CampaignEvents developers would like to do. And then send a change set up to gerrit for master and any other relevant branches.

I think it should be fairly safe to do so, but would like to hear from @cmelo @MHorsey-WMF @VPuffetMichel.

Agreed, we should go ahead asap

Agreed. What would it take to do so?

sbassett triaged this task as Medium priority.Nov 2 2023, 3:02 PM
sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett changed Risk Rating from N/A to Medium.

Agreed. What would it take to do so?

I've just made this task public (folks with certain acl*security access can do so). So now it should be possible for folks to push up any relevant backports through gerrit and have the bot comment here. Once the patch has been merged to master, it should then be removed from WMF production as a security patch, typically during the following week's train deploys. And we'll still plan to re-announce this at the end of the quarter with the supplemental security release (T347659).

Change 971248 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] SECURITY: Fix XSSs in EmailManager.js

https://gerrit.wikimedia.org/r/971248

Change 971183 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@REL1_41] SECURITY: Fix XSSs in EmailManager.js

https://gerrit.wikimedia.org/r/971183

@sbassett Thanks! I've pushed a fix for master and cherry-picked that to REL1_41. Should I ping someone to remind them of removing the patch from production when it's merged on gerrit?

@sbassett Thanks! I've pushed a fix for master and cherry-picked that to REL1_41. Should I ping someone to remind them of removing the patch from production when it's merged on gerrit?

scap should throw an error when the patch no longer applies, when releng attempt to stage the train. But I can keep watching this task, and when the change set for master gets merged, I'll remove the patch from T276237 and any future release dirs within /srv/patches on deployment.

Change 971183 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@REL1_41] SECURITY: Fix XSSs in EmailManager.js

https://gerrit.wikimedia.org/r/971183

Change 971248 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] SECURITY: Fix XSSs in EmailManager.js

https://gerrit.wikimedia.org/r/971248

Our part is done, I'll leave this open until the private security patch is removed from production.

Mstyles renamed this task from Various i18n-based XSSs in Special:EventDetails to CVE-2024-23171: Various i18n-based XSSs in Special:EventDetails.Jan 16 2024, 6:42 PM
Mstyles moved this task from Watching to Our Part Is Done on the Security-Team board.

@Daimona I did remove the patch from production