Security
Headlines
HeadlinesLatestCVEs

Headline

CVE-2023-29139: ⚓ T326293 API request timeout

An issue was discovered in the CheckUser extension for MediaWiki through 1.39.3. When a user with checkuserlog permissions makes many CheckUserLog API requests in some configurations, denial of service can occur (RequestTimeoutException or upstream request timeout).

CVE
#dos#auth#sap

**

API request timeout - CheckUserLog

Closed, ResolvedPublicSecurity

**

  • Edit Task

  • Edit Related Tasks…

  • Edit Related Objects…

  • Mute Notifications

  • Protect as security issue

  • Award Token

  • Flag For Later

Reason this is security flagged: I don’t know how vulnerable multiple executions of the same API request in the form of a DoS type attack would affect a wikis server status

Error Message 1:

{"error":{"code":"internal_api_error_Wikimedia\\RequestTimeout\\RequestTimeoutException","info":"[cb78d894-a1fc-4dec-8329-08d4bfe7985a] Caught exception of type Wikimedia\\RequestTimeout\\RequestTimeoutException","errorclass":"Wikimedia\\RequestTimeout\\RequestTimeoutException"},"servedby":"mw1361"}

Error message 2:

Affected Authentications: Logged in with checkuserlog permission
Unaffected: Logged in without checkuserlog permission & logged out

Affected Wikis: Group 0 & Group 1 wikis - on MW 1.40.0-wmf.17
Not affected Wikis: Group 2 wikis - on 1.40.0-wmf.14

Reproduction:

  1. Go to a project in which you have checkuserlog abilities
  2. make a request to the API CheckUserLog where you expect a non-zero result (could even just be a generic view all CU logs request)

Ways not to reproduce:

  1. Specifying parameters where the CU log would have zero enteries - this produces as it should, no results
  2. While not logged in OR without the checkuserlog permission - this results in the proper permission denied

Risk Rating

Low

Author Affiliation

Wikimedia Communities

Event Timeline

Comment Actions

I was about to suggest:
you can do something much simpler:
instead of:

  •       $this->addTables( \[ 'actor' \] );
          $this->addJoinConds( \[ 'actor' => \[ 'JOIN', 'actor\_id=cul\_actor' \] \] );
    

do:

        $this->addJoin( 'actor', null, 'actor\_id=cul\_actor' );

But it Api class doesn’t support it which baffling to me :/ to be fixed later.

Comment Actions

This is good to go IMO.

It can get deployed and then immediately added to gerrit. It was introduced recently so it shouldn’t be in any release branch.

Comment Actions

It is deployed so it shouldn’t block the train anymore. I’ll double check with secteam and then push it to gerrit and close this.

Comment Actions

Hey @Ladsgroup @taavi @Zabe -

Thanks for the quick response here. It looks like this made it to 1.40.0-wmf.17 but not 1.40.0-wmf.14, which is still where group 2 is for a little while, if I’m not mistaken. If there aren’t concerns about this vuln shortly existing there for a bit, then I suppose we don’t need to worry about 1.40.0-wmf.14.

SAL entry: https://sal.toolforge.org/log/LTTqgYUBa_6PSCT9o6gu

It can get deployed and then immediately added to gerrit. It was introduced recently so it shouldn’t be in any release branch.

This looks to be the bad change set? https://gerrit.wikimedia.org/r/871259. It’s fine to backport the security patch ASAP anyways, now that it’s patched in production, as CU isn’t bundled. We can also track it for the next supplemental release at T325849.

Thanks again.

sbassett changed the task status from Open to In Progress.Jan 5 2023, 5:22 PM

sbassett lowered the priority of this task from Unbreak Now! to Medium.

Comment Actions

Thanks for the quick response here. It looks like this made it to 1.40.0-wmf.17 but not 1.40.0-wmf.14, which is still where group 2 is for a little while, if I’m not mistaken. If there aren’t concerns about this vuln shortly existing there for a bit, then I suppose we don’t need to worry about 1.40.0-wmf.14.

The causing patch itself only made it into 1.40.0-wmf.17, so 1.40.0-wmf.14 is not affected by the vuln.

Comment Actions

The causing patch itself only made it into 1.40.0-wmf.17, so 1.40.0-wmf.14 is not affected by the vuln.

Ah, missed that, thanks!

sbassett changed Author Affiliation from N/A to Wikimedia Communities.Jan 9 2023, 10:17 PM

sbassett changed the visibility from “Custom Policy” to "Public (No Login Required)".

sbassett changed Risk Rating from N/A to Low.

Comment Actions

Apologies for not catching that in my review. Thanks for the quick response everyone.

Zabe closed this task as Resolved.Jan 9 2023, 10:22 PM

Zabe claimed this task.

Content licensed under Creative Commons Attribution-ShareAlike 3.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907