Similar to reported bug #T330085, this can be reproduced by the following:
1- Install MediaWiki.
2- Enable OATHAuth extension.
3-Enrol test user in MFA.
4- Obtain emergency/backup TOTP tokens during enrolment.
5- Re-use the same token by utilizing a race condition testing tool (for exmaple burp suite Turbo Intruder).

As per the discussion via email, it seems this is caused by the lack of any object cache that MediaWiki can use to temporarily store used TOTP (including scratch/emergency/recovery/backup tokens) to prevent reuse during the window till the database is updated.

The proposed fix is mostly about documentation. Update https://www.mediawiki.org/wiki/Extension:OATHAuth to include that use of ObjectCache is strongly advised. There's no README in the extension, so nothing to do there.

If we can try and highlight it in the web installer somehow too, that'd be good. That might be something worth forking to a followup task though. Maybe just an i18n message addition/update could be enough?

We may be able to issue a CVE too (it's not "insecure default permissions"; need to have a poke and see if we can find something to match). Either way, we should definitely note it in the next security update release. Should probably subtask this to T325840: Tracking bug for MediaWiki 1.35.10/1.38.6/1.39.3, and note it in T325843: Write and send release announcements for MediaWiki 1.35.10/1.38.6/1.39.3.

Trying to fix this more technically (ie so it works without ObjectCache) probably isn't feasible or sensible (like creating a DB table for "just this caching), but I also dont think OATHAuth should not work without ObjectCache (probably? Unless we want to try and fall back to something else that isn't just NullBagOfStuff... trying to use APC or something better than nothing? Obviously doesn't help in multi webserver setups, but will in a single setup, which statistically, if they haven't needed to setup caching, probably means it's a smaller wiki without many users/perf issues... But maybe it's a minor improvement).

I could attempt to try testing it again with object cache enabled but can't promise the same anytime sooner than the next two weeks.
Any specific cache setup to include in assessment?
A CVE would be nice :)

We're more than happy to request a CVE if we can find the right thing to label it as. Feel free to have a look and see if you can get something that lines up.

Regarding the caching, it shouldn't matter too much what you use... I've no idea what OS you're running MW on, but happy to advise further - https://www.mediawiki.org/wiki/Manual:Performance_tuning#Main_cache and using APC or Memcached should be more than enough (you can use the database too, but as we're talking about race conditions, it'd likely be slower too).

There's no massive rush, I don't think. The caching is definitely a key part, even if enabling it doesn't fix the issue completely. Documentation updates on the wiki can be done seperately, and without referencing this task/security issue, so don't really need to wait for that.

In T330086#8629904, @Reedy wrote:

Trying to fix this more technically (ie so it works without ObjectCache) probably isn't feasible or sensible (like creating a DB table for "just this caching), but I also dont think OATHAuth should not work without ObjectCache (probably? Unless we want to try and fall back to something else that isn't just NullBagOfStuff... trying to use APC or something better than nothing? Obviously doesn't help in multi webserver setups, but will in a single setup, which statistically, if they haven't needed to setup caching, probably means it's a smaller wiki without many users/perf issues... But maybe it's a minor improvement).

If a cache is absolutely needed, ObjectCache::getLocalServerInstance( CACHE_ANYTHING ) will first try APCu, then any other configured cache, and then CACHE_DB (if it's usable) before returning a NullBagOStuff.

In T330086#8630505, @Legoktm wrote:

In T330086#8629904, @Reedy wrote:

Trying to fix this more technically (ie so it works without ObjectCache) probably isn't feasible or sensible (like creating a DB table for "just this caching), but I also dont think OATHAuth should not work without ObjectCache (probably? Unless we want to try and fall back to something else that isn't just NullBagOfStuff... trying to use APC or something better than nothing? Obviously doesn't help in multi webserver setups, but will in a single setup, which statistically, if they haven't needed to setup caching, probably means it's a smaller wiki without many users/perf issues... But maybe it's a minor improvement).

If a cache is absolutely needed, ObjectCache::getLocalServerInstance( CACHE_ANYTHING ) will first try APCu, then any other configured cache, and then CACHE_DB (if it's usable) before returning a NullBagOStuff.

EmptyBagOStuff is what we both meant.

Defaulting to APCu in the case where it's >1 server isn't helpful... But if we checked if MediaWikiServices::getInstance()->getMainObjectStash() instanceof EmptyBagOStuff, and then called ObjectCache::getLocalServerInstance( CACHE_ANYTHING ) (doesn't look to be exposed via MediaWikiServices?) if it is a EmptyBagOStuff as the fallback to at least try some other options...

That does feel like an improvement on the current state of affairs?

In T330086#8630400, @Reedy wrote:

We're more than happy to request a CVE if we can find the right thing to label it as. Feel free to have a look and see if you can get something that lines up.

https://cwe.mitre.org/data/definitions/362.html
This is the closest CWE mapping to race conditions.

+1 to @Reedy's patch above. Could this just get pushed through gerrit as an OATHAuth "performance improvement" with a benign commit message?

I don't see why not to be honest...

In T330086#8630531, @Reedy wrote:

index 336083f..9e61be4 100644
--- a/src/Key/TOTPKey.php
+++ b/src/Key/TOTPKey.php
@@ -21,6 +21,7 @@ namespace MediaWiki\Extension\OATHAuth\Key;
 
 use Base32\Base32;
 use DomainException;
+use EmptyBagOStuff;
 use Exception;
 use jakobo\HOTP\HOTP;
 use MediaWiki\Extension\OATHAuth\IAuthKey;
@@ -29,6 +30,7 @@ use MediaWiki\Extension\OATHAuth\OATHUserRepository;
 use MediaWiki\Logger\LoggerFactory;
 use MediaWiki\MediaWikiServices;
 use MWException;
+use ObjectCache;
 use Psr\Log\LoggerInterface;
 
 /**
@@ -143,6 +145,12 @@ class TOTPKey implements IAuthKey {
 
                // Prevent replay attacks
                $store = MediaWikiServices::getInstance()->getMainObjectStash();
+
+               if ( $store instanceof EmptyBagOStuff ) {
+                       // Try and find some usable cache if the MainObjectStash isn't useful
+                       $store = ObjectCache::getLocalServerInstance( CACHE_ANYTHING );
+               }
+
                $uid = MediaWikiServices::getInstance()
                        ->getCentralIdLookupFactory()
                        ->getLookup()

Code-Review +2.

Change 890915 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/OATHAuth@master] TOTPKey: Add better fallback attempts to find a useable cache

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

Change 890915 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@master] TOTPKey: Add better fallback attempts to find a useable cache

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

Change 890853 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/OATHAuth@REL1_39] TOTPKey: Add better fallback attempts to find a useable cache

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

Change 890854 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/OATHAuth@REL1_38] TOTPKey: Add better fallback attempts to find a useable cache

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

Change 890855 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/OATHAuth@REL1_35] TOTPKey: Add better fallback attempts to find a useable cache

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

Change 890853 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@REL1_39] TOTPKey: Add better fallback attempts to find a useable cache

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

Change 890854 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@REL1_38] TOTPKey: Add better fallback attempts to find a useable cache

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

Change 890855 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@REL1_35] TOTPKey: Add better fallback attempts to find a useable cache

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

@Reedy Have you looked into the proposed CVE category?

In T330086#8710896, @MajidAlqabandi wrote:

@Reedy Have you looked into the proposed CVE category?

Likely Incorrect Access Controls or Insecure Permissions for the vulnerability type. Or possibly just Other. The attack type is Remote and the Impact would be Escalation of Privileges and Information Disclosure.

Shall I proceed and request for one?

In T330086#8710949, @MajidAlqabandi wrote:

Shall I proceed and request for one?

As the ostensible "vendors" of the MediaWiki extension, we would typically request them just prior to our quarterly security release.

Great, I will be waiting for that. Thanks for the update.

@MajidAlqabandi as per our original discussion, I've now updated the onwiki documentation for the extension to advise people to setup caching when using it - https://www.mediawiki.org/w/index.php?title=Extension%3AOATHAuth&diff=5851727&oldid=5843636&diffmode=source

Let me know if you think that's enough, and for example, in your case, if that would've encouraged you to setup caching (which would have prevented this issue in the edge case). Obviously with the hardening patch tagged.

Wording can be improved/changed later, of course. But that's hopefully an improvement...

@Reedy Fair enough, I was thinking if someone would like to read more on the topic, perhaps mentioned this TT?
Just thinking out loud on how to educate people on race conditions.

We can, but most people probably don’t care.

When it’s public we can indeed link it for reference.

We can, but most people probably don’t care.

When it’s public we can indeed link it for reference.

I hear you. Sounds good.

@MajidAlqabandi guessing you want crediting on https://security.wikimedia.org/hall-of-fame/ ? :)

In T330086#8802375, @Reedy wrote:

@MajidAlqabandi guessing you want crediting on https://security.wikimedia.org/hall-of-fame/ ? :)

That would be awesome. Sure thing!

@Reedy Can we disclose?
Am working on a blog post for this and wanted to check first. Also, would love to be listed in the HoF :)

In T330086#8876221, @MajidAlqabandi wrote:

@Reedy Can we disclose?
Am working on a blog post for this and wanted to check first. Also, would love to be listed in the HoF :)

Yes, we can disclose.

Change 923570 had a related patch set uploaded (by SBassett; author: SBassett):

[wikimedia/security/landing-page@master] Add Majid Alqabandi to Security Team Hall of Fame

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

Change 923570 merged by jenkins-bot:

[wikimedia/security/landing-page@master] Add Majid Alqabandi to Security Team Hall of Fame

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

Change 923572 had a related patch set uploaded (by SBassett; author: SBassett):

[wikimedia/security/landing-page@master] Add Majid Alqabandi to Security Team Hall of Fame (build step)

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

Change 923572 merged by jenkins-bot:

[wikimedia/security/landing-page@master] Add Majid Alqabandi to Security Team Hall of Fame (build step)

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

@MajidAlqabandi - You've officially made the hall of fame, congratulations: https://security.wikimedia.org/hall-of-fame/