Page MenuHomePhabricator

User scripts shouldn't run on Special:Manage_Two-factor_authentication
Closed, ResolvedPublicSecurity

Description

Users with the oathauth-enable right can manage two-factor authentification on the Special:Manage_Two-factor_authentication page (for example, https://en.wikipedia.org/wiki/Special:Manage_Two-factor_authentication), but unlike other security-sensitive pages like Special:Preferences and Special:UserLogin, local scripts (Common.js, gadgets, user scripts, etc.) are allowed to run on this page.

It seems like all important actions on these pages require confirmation other than just a button click, but an attacker could try to confuse the user by altering text on the page using their script, prompting the user to perform an action they need. What bothers me even more, the attacker could intercept the code the user enters into some of the forms (I personally met a form like this at https://ru.wikipedia.org/w/index.php?title=Special:Manage_Two-factor_authentication&action=disable&module=totp&uselang=en).

Details

Author Affiliation
Wikimedia Communities
Related Gerrit Patches:
mediawiki/extensions/OATHAuth : REL1_31SECURITY: Disallow user JS at our special pages
mediawiki/extensions/OATHAuth : REL1_33SECURITY: Disallow user JS at our special pages
mediawiki/extensions/OATHAuth : REL1_34SECURITY: Disallow user JS at our special pages
mediawiki/extensions/OATHAuth : masterSECURITY: Disallow user JS at our special pages

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 24 2020, 4:08 PM
Urbanecm claimed this task.Jan 24 2020, 8:44 PM
Restricted Application added a project: User-Urbanecm. · View Herald TranscriptJan 24 2020, 8:44 PM

This situation should be fairly low-risk IMO, though the Security-Team wouldn't be opposed to this kind of code-hardening in general. I'd imagine the solution should look like the most recent special page to receive this treatment (that I'm aware of), e.g. T192134.

Well, getting scratch codes or the QR code can be dangerous. Here you are :).

scratch codes or the QR code

Right, this is even worse than intercepting the code.

Reedy triaged this task as Low priority.Jan 25 2020, 9:35 AM
Reedy added a subscriber: Reedy.

Not just the QR code... We list the secret on the page in clear text

Commit summary is a bit odd... "our special pages"

I think after this is deployed, it can go into gerrit, and be backported to REL1_31, REL1_33, REL1_34

What bothers me even more, the attacker could intercept the code the user enters into some of the forms (I personally met a form like this at https://ru.wikipedia.org/w/index.php?title=Special:Manage_Two-factor_authentication&action=disable&module=totp&uselang=en).

This part doesn't feel like so much of an issue. You can't use a scratch token or OTP twice (the library prevents replay)

Though as per @Urbanecm's patch, knowing what was input on Special/DisableOATHForUser.php could be useful (though Wikimedia doesn't use it yet), intercepting/getting the users that have had 2FA disabled

Reedy added a comment.Jan 25 2020, 9:49 AM

Deployed to .15 and .16

Not just the QR code... We list the secret on the page in clear text

Commit summary is a bit odd... "our special pages"
I think after this is deployed, it can go into gerrit, and be backported to REL1_31, REL1_33, REL1_34

What bothers me even more, the attacker could intercept the code the user enters into some of the forms (I personally met a form like this at https://ru.wikipedia.org/w/index.php?title=Special:Manage_Two-factor_authentication&action=disable&module=totp&uselang=en).

This part doesn't feel like so much of an issue. You can't use a scratch token or OTP twice (the library prevents replay)

Well once you have the shared secret, you can just generate OTPs freely.

Though as per @Urbanecm's patch, knowing what was input on Special/DisableOATHForUser.php could be useful (though Wikimedia doesn't use it yet), intercepting/getting the users that have had 2FA disabled

You could submit the form with a different username than the admin entered, and remove 2FA from your target account.

Reedy added a comment.Jan 25 2020, 2:26 PM

Not just the QR code... We list the secret on the page in clear text

Commit summary is a bit odd... "our special pages"
I think after this is deployed, it can go into gerrit, and be backported to REL1_31, REL1_33, REL1_34

What bothers me even more, the attacker could intercept the code the user enters into some of the forms (I personally met a form like this at https://ru.wikipedia.org/w/index.php?title=Special:Manage_Two-factor_authentication&action=disable&module=totp&uselang=en).

This part doesn't feel like so much of an issue. You can't use a scratch token or OTP twice (the library prevents replay)

Well once you have the shared secret, you can just generate OTPs freely.

Yes, I know. But on the link given (to disable 2FA) you don't get the secret, you only can enter a OTP (or a scratch token)

Though as per @Urbanecm's patch, knowing what was input on Special/DisableOATHForUser.php could be useful (though Wikimedia doesn't use it yet), intercepting/getting the users that have had 2FA disabled

You could submit the form with a different username than the admin entered, and remove 2FA from your target account.

Yes, I know that. I didn't say it wasn't necessary, I was agreeing it was useful there, as an attacker can glean information too

Reedy added a comment.Feb 3 2020, 4:15 PM

Urbanecm moved this task from Backlog to Waiting on review on the User-Urbanecm board.

This has already been reviewed and deployed as per

Deployed to .15 and .16

Patches can go into gerrit, and backported where appropriate. So it can ride the train and be removed from being local patches

Reedy moved this task from Incoming to In Progress on the Security-Team board.Feb 3 2020, 4:41 PM

Patches can go into gerrit, and backported where appropriate. So it can ride the train and be removed from being local patches

Krinkle renamed this task from Local scripts shouldn't run on Special:Manage_Two-factor_authentication to User scripts shouldn't run on Special:Manage_Two-factor_authentication.Feb 13 2020, 5:26 PM
sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".Feb 13 2020, 8:11 PM

Change 572077 had a related patch set uploaded (by SBassett; owner: Urbanecm):
[mediawiki/extensions/OATHAuth@master] SECURITY: Disallow user JS at our special pages

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

Change 572078 had a related patch set uploaded (by SBassett; owner: Urbanecm):
[mediawiki/extensions/OATHAuth@REL1_34] SECURITY: Disallow user JS at our special pages

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

Change 572083 had a related patch set uploaded (by SBassett; owner: SBassett):
[mediawiki/extensions/OATHAuth@REL1_33] SECURITY: Disallow user JS at our special pages

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

Change 572086 had a related patch set uploaded (by SBassett; owner: SBassett):
[mediawiki/extensions/OATHAuth@REL1_31] SECURITY: Disallow user JS at our special pages

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

As per the previous, similar code-hardening (T192134), the backports are up on gerrit and a CVE isn't warranted, though I'd imagine we'll include this as part of the next (security) release (T240392).

Would you mind adding me to T240392?

Would you mind adding me to T240392?

Done, though it's just a tracking bug for the quarterly releases. Not much to see.

Change 572077 merged by jenkins-bot:
[mediawiki/extensions/OATHAuth@master] SECURITY: Disallow user JS at our special pages

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

Change 572078 merged by jenkins-bot:
[mediawiki/extensions/OATHAuth@REL1_34] SECURITY: Disallow user JS at our special pages

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

Change 572083 merged by jenkins-bot:
[mediawiki/extensions/OATHAuth@REL1_33] SECURITY: Disallow user JS at our special pages

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

Change 572086 merged by SBassett:
[mediawiki/extensions/OATHAuth@REL1_31] SECURITY: Disallow user JS at our special pages

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

sbassett closed this task as Resolved.Feb 18 2020, 2:48 PM

Backports to release branches completed.