Creating a new botpassword allows you to take control of an account in much the same way as changing the password does as it essentially creates a new password.
Thus it should call SpecialPage::checkLoginSecurityLevel()
Maybe related T194204
Bawolff | |
May 9 2018, 7:25 AM |
F20989629: 0001-SECURITY-Enable-elevated-login-security-for-bot-pass.patch | |
Jun 10 2018, 4:13 PM |
F18103230: 0002-SECURITY-Special-BotPasswords-should-reauthenticate.patch | |
May 9 2018, 7:25 PM |
F18103229: 0001-SECURITY-Add-getLoginSecurityLevel-support-to-FormSp.patch | |
May 9 2018, 7:25 PM |
Creating a new botpassword allows you to take control of an account in much the same way as changing the password does as it essentially creates a new password.
Thus it should call SpecialPage::checkLoginSecurityLevel()
Maybe related T194204
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Reedy | T199021 Release MediaWiki 1.27.5/1.29.3/1.30.1/1.31.1 | |||
Resolved | Reedy | T181665 Tracking bug for 1.27.5/1.29.3/1.30.1/1.31.1 security release | |||
Open | None | T197160 All security-sensitive MediaWiki functionality should require elevated security | |||
Resolved | Anomie | T194237 bot passwords should call checkLoginSecurityLevel |
Hmm. Doing this at a basic level would be pretty simple, but loses form data if the user takes too long on the edit screen.
Fixing that can copy some logic from AuthManagerSpecialPage which already does something similar, but it's a bit of a big change for a security patch. I wouldn't be opposed to submitting the first one (without the "SECURITY" tag) publicly for normal review.
Given this is a hardening measure, and not outright vulnerability, i think its fine to develop this in gerrit.
[I was going to deploy this today given the attack happening again. However, when I put patch on mwdebug1002, it didn't seem to work (Despite working locally). I'm not sure why, but in any case I'm going to wait until monday to figure it out]
Ok, it appears the other one isn't merged yet.
I'm just going to throw the second one in gerrit and let it ride the train.
The patch is deployed. We probably need to do a security release for 1.31 and before.
I've just done cherry picks of the public patch onto 1.27, 1.29, 1.30, 1.31 with a fixed bug reference
https://gerrit.wikimedia.org/r/#/q/I9a38a3109492753fff1f33c0f280e5b0f1fc1a76
Marking as resolved for tracking purposes.
Could be opened up in advance, as per Brian it's hardening, but it's not going to harm sitting closed till the release