| Bawolff |
| Jun 15 2018, 6:42 AM |
| F22260739: T197279.patch |
| Jun 15 2018, 8:30 AM |
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
Details
Related Objects
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | dancy | T302086 Set scap minimum python version to 3.7 | |||
| Resolved | None | T247045 Migrate all of production metal and VMs to Buster or later | |||
| Resolved | akosiaris | T249724 Track and remove jessie based container images from production | |||
| Resolved | Jdforrester-WMF | T224908 Drop jessie testing support | |||
| Resolved | Jdforrester-WMF | T224907 Drop php55 testing support | |||
| Resolved | Reedy | T205039 Release MediaWiki 1.27.6/1.30.2/1.31.2/1.32.2 | |||
| Resolved | Reedy | T205041 Tracking bug for 1.27.6/1.30.2/1.31.2/1.32.2 security release | |||
| Resolved | Bawolff | T197279 Direct POST to Special:ChangeEmail will bypass reauth check |
- Mentioned In
- T224499: RELEASE-NOTES for 1.27.6/1.30.2/1.31.2/1.32.2
T205041: Tracking bug for 1.27.6/1.30.2/1.31.2/1.32.2 security release
T205048: Obtain CVEs for 1.27.6/1.30.2/1.31.2/1.32.2 security releases
T209794: Need to make a limit of count of attempts to change email address - Mentioned Here
- rMW3617c982c9db: Use AuthManager on special pages
T205041: Tracking bug for 1.27.6/1.30.2/1.31.2/1.32.2 security release
Event Timeline
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.
Am I the only one wondering why BotPasswords even allows using anything but api.php?
In T197279#4287850, @MaxSem wrote: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
[09:03] bawolff !log deploy patch T197279
Ok, it appears this got undeployed, as I accidentally put the patch in instead of the appropriate place, and that's how it got dropped. Redployed it today
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. :-(
@Legoktm: I am reopening this task because there is no patch merged in the MediaWiki codebase, if I understand correctly.
In T197279#5214082, @Aklapper wrote:@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"
Re-closing for ease of tracking above
In T197279#5216519, @Reedy wrote: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 T197279#5216680, @Jdforrester-WMF wrote:In T197279#5216519, @Reedy wrote: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 :)
Change 514762 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_27] SECURITY: Fix reauth in Special:ChangeEmail
Change 514762 merged by Reedy:
[mediawiki/core@REL1_27] SECURITY: Fix reauth in Special:ChangeEmail
Change 514773 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_30] SECURITY: Fix reauth in Special:ChangeEmail
Change 514773 merged by Reedy:
[mediawiki/core@REL1_30] SECURITY: Fix reauth in Special:ChangeEmail
Change 514753 merged by jenkins-bot:
[mediawiki/core@master] SECURITY: Fix reauth in Special:ChangeEmail
Change 514849 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_31] SECURITY: Fix reauth in Special:ChangeEmail
Change 514849 merged by jenkins-bot:
[mediawiki/core@REL1_31] SECURITY: Fix reauth in Special:ChangeEmail
Change 514949 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_32] SECURITY: Fix reauth in Special:ChangeEmail
Change 514949 merged by jenkins-bot:
[mediawiki/core@REL1_32] SECURITY: Fix reauth in Special:ChangeEmail
Change 514973 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_33] SECURITY: Fix reauth in Special:ChangeEmail
Change 514973 merged by jenkins-bot:
[mediawiki/core@REL1_33] SECURITY: Fix reauth in Special:ChangeEmail
Anyone know offhand how long this was an issue for?
I'm guessing it's since at least the rewrite to use authmanager in I8b52ec / 3617c982c9db793515818e1468fa827ae5880358 but might be potentially longer (I can't see anything offhand in the change that specifically changed that behaviour)