Page MenuHomePhabricator

Direct POST to Special:ChangeEmail will bypass reauth check
Closed, ResolvedPublic

Description

CVE: CVE-2019-12468

It looks like User:Sundar was recently compromised via js.

Logs have something like:

  • At 2018-06-15T04:27:50 they get reauth error at botpassword
  • At 2018-06-15T04:27:51 they changed email at tawiki via Special:ChangeEmail

So it would look like attacker somehow bypassed the reauth stage to change the email. Need to investigate further

see T194204

Event Timeline

Bawolff created this task.Jun 15 2018, 6:42 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 15 2018, 6:42 AM
This comment was removed by Reedy.

Also of interest, the url in the log is /w/index.php?title=Special:ChangeEmail despite it being at tawiki, where Special should have been translated. This suggests its directly posting to the page without following usual links.

Also, note, the reauth log entry has the same id (WyNARgpAADoAAExxuzAAAABN) as the email changed log entry.

So maybe if you directly POST to special:Changeemail, the change will go through even if a reauth is needed?

Confirmed direct post to Special:ChangeEmail will bypass the reauth workflow.

Bawolff renamed this task from Possible vulnerability in how Special:Emailuser does reauth to Direct POST to Special:ChangeEmail will bypass reauth check.Jun 15 2018, 7:52 AM
MaxSem added a subscriber: MaxSem.Jun 15 2018, 8:12 AM

Am I the only one wondering why BotPasswords even allows using anything but api.php?

Am I the only one wondering why BotPasswords even allows using anything but api.php?

Bot passwords does not allow using things other than API. Person first tried to add a bot password but failed, and then moved on to Special:ChangeEmail

Bawolff added a comment.EditedJun 15 2018, 8:26 AM

[09:03] bawolff !log deploy patch T197279

Ok, it appears this got undeployed, as I accidentally put the patch in /srv/1.32.0-wmf.999/core/03-T197279.patch instead of the appropriate place, and that's how it got dropped. Redployed it today

Legoktm closed this task as Resolved.Oct 22 2018, 3:37 PM
Legoktm assigned this task to Bawolff.
Legoktm added a subscriber: Legoktm.

Closing this as there's a patch fixing it on Wikimedia sites. We'll make this public in the next MediaWiki security release.

Closing this as there's a patch fixing it on Wikimedia sites. We'll make this public in the next MediaWiki security release.

This still hasn't happened, 10 months after the patch was deployed to production. :-(

Aklapper reopened this task as Open.May 27 2019, 9:15 AM

@Legoktm: I am reopening this task because there is no patch merged in the MediaWiki codebase, if I understand correctly.

Reedy added a subscriber: Reedy.May 27 2019, 1:25 PM

@Legoktm: I am reopening this task because there is no patch merged in the MediaWiki codebase, if I understand correctly.

That's what we normally do, to make it easier to keep track of the status of the subtasks... As we don't have a status (that's outwardly viewable) for like "done but not completely finished"

Reedy closed this task as Resolved.May 28 2019, 1:51 PM

Re-closing for ease of tracking above

Re-closing for ease of tracking above

It'd be much easier if the tracking what was where was done on T205041, rather than mis-categorise this as Resolved when it isn't.

Reedy added a comment.May 28 2019, 2:41 PM

Re-closing for ease of tracking above

It'd be much easier if the tracking what was where was done on T205041, rather than mis-categorise this as Resolved when it isn't.

In the same way that we resolve bugs that are fixed in master, but not deployed in WMF production? ;)

Ok, so this patch depends on https://github.com/wikimedia/mediawiki/commit/3617c982c9db793515818e1468fa827ae5880358 (which wasn't in REL1_27, but was backported) and also https://github.com/wikimedia/mediawiki/commit/bfc4e41636aca33b943f8522024bd9f8eeac1977 (which isn't in REL1_31 or before)

Going to do some supporting backports now :)

Reedy changed the visibility from "Custom Policy" to "Public (No Login Required)".Jun 6 2019, 4:00 PM

Change 514762 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_27] SECURITY: Fix reauth in Special:ChangeEmail

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

Change 514762 merged by Reedy:
[mediawiki/core@REL1_27] SECURITY: Fix reauth in Special:ChangeEmail

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

Change 514773 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_30] SECURITY: Fix reauth in Special:ChangeEmail

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

Change 514773 merged by Reedy:
[mediawiki/core@REL1_30] SECURITY: Fix reauth in Special:ChangeEmail

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

Change 514753 merged by jenkins-bot:
[mediawiki/core@master] SECURITY: Fix reauth in Special:ChangeEmail

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

Change 514849 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_31] SECURITY: Fix reauth in Special:ChangeEmail

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

Change 514849 merged by jenkins-bot:
[mediawiki/core@REL1_31] SECURITY: Fix reauth in Special:ChangeEmail

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

Change 514949 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_32] SECURITY: Fix reauth in Special:ChangeEmail

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

Change 514949 merged by jenkins-bot:
[mediawiki/core@REL1_32] SECURITY: Fix reauth in Special:ChangeEmail

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

Change 514973 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_33] SECURITY: Fix reauth in Special:ChangeEmail

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

Change 514973 merged by jenkins-bot:
[mediawiki/core@REL1_33] SECURITY: Fix reauth in Special:ChangeEmail

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

Reedy updated the task description. (Show Details)Jun 17 2019, 5:31 PM
Reedy added a comment.Jun 17 2019, 5:38 PM

Anyone know offhand how long this was an issue for?

I'm guessing it's since at least the rewrite to use authmanager in I8b52ec8ddf494f23941807638f149f15b5e46b0c / 3617c982c9db793515818e1468fa827ae5880358 but might be potentially longer (I can't see anything offhand in the change that specifically changed that behaviour)