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).
**
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:
- Go to a project in which you have checkuserlog abilities
- 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:
- Specifying parameters where the CU log would have zero enteries - this produces as it should, no results
- 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