Page MenuHomePhabricator

CVE-2025-6926: SUL3 local login should not count for security reauthentication
Closed, ResolvedPublicSecurity

Description

Certain pages must be used shortly after login; if that's not the case, the user is asked to reauthenticate. (See $wgReauthenticateTime.) This is to prevent an attacker from stealing a session cookie and then e.g. changing the password.

SUL3 handles authentication as the combination of the user-visible authentication action on the central domain plus an invisible login on the local domain. The local login happens not only when the user successfully logged in or signed up on the central domain, but also when they were already logged in there. That means just visiting the local login page will count as an (automatically successful) local reauthentication while the user is centrally logged in. This lets an attacker trivially circumvent security checks.

See also T389009: CVE-2025-6597: MediaWiki should not consider autocreation as login for the purposes of security reauthentication.

Event Timeline

Core patch (needs to be applied on top of the one in T389009):

CentralAuth patch:

With the patch for T389009 now deployed, I think we should be able to get the above patches out sometime this week or during next week's security deployment window. I'll try to test these a bit, but it would be great if we could get someone with CA experience to have a look as well.

I spent some time testing this today (and demoed it on a call with @Tgr). The test plan was as follows:

@note: Testing with Special:BotPasswords page because it has not been migrated to the shared domain yet. We want to trigger re-authentication (on the shared domain) and then end up on the local domain's bot passwords page. A special page like Special:BotPasswords is not a very good example to test this because that will always trigger re-authentication based on the last login timestamp of the central session (since that has already been migrated to the shared domain).

Before the patches (core and CentralAuth) were applied:

  1. Set $wgReauthenticationTime = [ 'default' => 120 /* 2min */ ]; (short enough to wait during testing). This defaults to 5 minutes (and is what is used in production today).
  2. Ensure SUL3 is enabled.
  3. On a local SUL3 wiki, visit the login page (Special:Userlogin)
  4. You'll be redirected to the shared domain login page, and then you'll log in there.
  5. After login (in step 4) is successful, you'll be redirected back to the local domain, and authentication will continue.
  6. You'll be logged into the local domain.
  7. Wait for 3 minutes (so that we're sure the re-authentication time takes effect).
  8. Clear local domain authentication cookies (to fake session expiration), then refresh the page to get a new local logged-in session (will happen in the background).
  9. Visit the Special:BotPasswords page on your local domain
  10. You won't be asked to re-authenticate since the local login (on step 8).

Screenshot 2025-06-25 at 2.58.42 PM.png (1×2 px, 205 KB)

After the patches (core and CentralAuth) were applied:

  1. Set $wgReauthenticationTime = [ 'default' => 120 /* 2min */ ]; (short enough to wait during testing). This defaults to 5 minutes (and is what is used in production today).
  2. Ensure SUL3 is enabled.
  3. On a local SUL3 wiki, visit the login page (Special:Userlogin)
  4. You'll be redirected to the shared domain login page, and then you'll log in there.
  5. After login (in step 4) is successful, you'll be redirected back to the local domain, and authentication will continue.
  6. You'll be logged into the local domain.
  7. Wait for 3 minutes (so that we're sure the re-authentication time takes effect).
  8. Clear local domain authentication cookies (to fake session expiration), then refresh the page to get a new local logged-in session (will happen in the background).
  9. Visit the Special:BotPasswords page on your local domain
  10. You will be redirected to the shared domain (with &force=local&forceOriginal=BotPasswords URL params) and asked to re-authenticate.

Screenshot 2025-06-25 at 2.58.05 PM.png (1×1 px, 129 KB)

Other tests done on the side:

  • Verified that re-authentication that used to work for pages migrated to the shared domain (like Special:ChangePassword) still works correctly today.
  • Forcing re-authentication with the action=force query param like for <auth domain>/wiki/enwiki/Special:UserLogin?action=force still works as expected today.

In conclusion, I think this works as expected. Thank you, Gergo. If I'm not missing anything, this can be deployed. I suggested some improvements (non-blockers) to Gergo privately on Slack.

@Tgr @DAlangi_WMF - Can we plan to get this out today during today's late backport window or after that as a security deployment? Happy to assist with that.

@Tgr @DAlangi_WMF - Can we plan to get this out today during today's late backport window or after that as a security deployment? Happy to assist with that.

Sure @sbassett, I can help with testing.

The patches from T389010#10916135 were deployed to wmf.7 today. Changes look stable. Thanks very much to @DAlangi_WMF for production-testing, post-deployment!

The patches from T389010#10916135 were deployed to wmf.7 today. Changes look stable. Thanks very much to @DAlangi_WMF for production-testing, post-deployment!

Ack! Thanks a lot @sbassett for deploying. Tested this on testwiki and it looks good. Cc @Tgr https://phabricator.wikimedia.org/F62543963 (for confirmation). It also works with 2FA (since my account has that enabled by default).

Is this presuambly scope for reusing CVE-2025-6597 like T389009: CVE-2025-6597: MediaWiki should not consider autocreation as login for the purposes of security reauthentication? Or do we want to allocate its own?

Not sure what the CVE best practice is, tbh. While they're basically the same bug (at least as far as I can tell) I feel like this one could warrant its own CVE since it's now in the context of SUL3, which was a pretty significant change to MediaWiki.

Reedy renamed this task from SUL3 local login should not count for security reauthentication to CVE-2025-6926: SUL3 local login should not count for security reauthentication.Jun 30 2025, 2:28 PM

It's the same type of mistake but in a different workflow, one has been around for several years and is hard to trigger by accident, the other was introduced a few months ago and is very easy to trigger accidentally. Separate CVEs seems like the way to go.

Change #1165076 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/core@REL1_43] SECURITY: Allow extensions to supress the reauth flag on login

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

Change #1165090 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/core@REL1_39] SECURITY: Allow extensions to supress the reauth flag on login

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

Change #1165102 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/core@REL1_44] SECURITY: Allow extensions to supress the reauth flag on login

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

Change #1165117 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/core@master] SECURITY: Allow extensions to supress the reauth flag on login

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

Change #1165090 merged by jenkins-bot:

[mediawiki/core@REL1_39] SECURITY: Allow extensions to supress the reauth flag on login

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

Change #1165136 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/core@REL1_42] SECURITY: Allow extensions to supress the reauth flag on login

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

Change #1165102 merged by jenkins-bot:

[mediawiki/core@REL1_44] SECURITY: Allow extensions to supress the reauth flag on login

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

Change #1165076 merged by jenkins-bot:

[mediawiki/core@REL1_43] SECURITY: Allow extensions to supress the reauth flag on login

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

Change #1165117 merged by jenkins-bot:

[mediawiki/core@master] SECURITY: Allow extensions to supress the reauth flag on login

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

Change #1165136 merged by jenkins-bot:

[mediawiki/core@REL1_42] SECURITY: Allow extensions to supress the reauth flag on login

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

Change #1165164 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@master] SECURITY: Do not count SUL3 autologin as reauthentication

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

Change #1165511 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@REL1_44] SECURITY: Do not count SUL3 autologin as reauthentication

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

Change #1165512 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@REL1_43] SECURITY: Do not count SUL3 autologin as reauthentication

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

Change #1165164 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] SECURITY: Do not count SUL3 autologin as reauthentication

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

Change #1165512 abandoned by Reedy:

[mediawiki/extensions/CentralAuth@REL1_43] SECURITY: Do not count SUL3 autologin as reauthentication

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

Change #1165511 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@REL1_44] SECURITY: Do not count SUL3 autologin as reauthentication

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

sbassett triaged this task as Medium priority.Jul 8 2025, 8:36 PM
sbassett removed a project: Patch-For-Review.
sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett changed Risk Rating from N/A to Medium.