CVE-2023-37255: ⚓ T333569 Special:CheckUser 'get edits' is vulnerable to HTML injection through user agent string

**

Special:CheckUser ‘get edits’ is vulnerable to HTML injection through user agent string

Closed, ResolvedPublicSecurity

**

• Edit Task

• Edit Related Tasks…

• Edit Related Objects…

• Mute Notifications

• Protect as security issue

• Award Token

• Flag For Later

Steps to reproduce

• Modify your user agent to include HTML
• Make a test edit or logged action
• Load Special:CheckUser
• Run a check using the ‘get edits’ type
• Notice that the HTML isn’t escaped

Example
Override your user agent string (example using Firefox about:config):

Inspecting the logged edit using inspect element:

Other information
The user agent is truncated before insertion into the database at 255 bytes which could make it harder to abuse. Only occurs when running the ‘get edits’ check type.

Risk Rating

Medium

Author Affiliation

Wikimedia Communities

• Mentions

Event Timeline

Dreamy_Jazz renamed this task from Special:CheckUser vulnerable to HTML injection through user agent string to Special:CheckUser ‘get edits’ is vulnerable to HTML injection through user agent string.Mar 30 2023, 2:44 PM

Comment Actions

Please add a SECURITY: prefix to the commit message.

Done. Updated patch provided below:

Comment Actions

Added prefix, will deploy now. I was able to reproduce the issue and test the fix locally.

0001-SECURITY-Escape-user-agent-before-showing-in-Special.patch1 KBDownload

Comment Actions

@Reedy I wonder if we can include this in the security release that you pre-announced yesterday? Or is this too short notice? (Security deployment is currently ongoing, btw.)

Comment Actions

This fix needs backporting to 1.39 and 1.40. 1.38 and before doesn’t seem to have this problem.

Comment Actions

This fix needs backporting to 1.39 and 1.40. 1.38 and before doesn’t seem to have this problem.

Agreed, I just checked the same thing. (The bug was introduced in 6d6b229c02, the old code was using htmlspecialchars( $row->cuc_agent ) and thus safe.)

Comment Actions

The fix should be deployed on wmf.1 and wmf.2 now. (I used deploy_security.py.)

Comment Actions

Can verify this deployed correctly.

Was able to verify without the need to spoof my user agent to include HTML as there is separate bug with the template parser that makes the user agent not display if there is a specific character (which is how I found this issue) when the value is escaped. That issue is rare (only seen it once) and isn’t a security issue. Will be looking for the associated task and if not filing one.

Comment Actions

Thanks all for the quick patch and deploy.

@Reedy I wonder if we can include this in the security release that you pre-announced yesterday? Or is this too short notice? (Security deployment is currently ongoing, btw.)

Since CheckUser isn’t bundled with core, it would go out as part of a supplemental security releases (current tracking bug: T325849). I don’t know if I’d agree there’s any sense of urgency here - anything within the supplemental release can be made public and have backports performed once the issue has been patched in Wikimedia production. So this issue could be a part of the next supplemental security release, but be disclosed and backported much sooner.

Comment Actions

So this issue could be a part of the next supplemental security release, but be disclosed and backported much sooner.

Considering that users of the release branches will be pulling the changes soon, getting this merged into the release branches before the git pull is run makes sense to me. Therefore, given that this seems to be an okay thing once it’s fixed in WMF production (which it has been), I’ll do as such now.

A useful side effect of getting this fix out is that it makes fixing a non-security bug easier as this method of escaping seems to prevent some unicode characters being displayed (see T333573). The temporary fix (unless I can find the core issue) would be to use htmlspecialchars to escape the value. This method would conflict with the currently deployed security patch.

Comment Actions

Considering that users of the release branches will be pulling the changes soon, getting this merged into the release branches before the git pull is run makes sense to me. Therefore, given that this seems to be an okay thing once it’s fixed in WMF production (which it has been), I’ll do as such now.

That’s fine - I’ve got it tracked for the next supplemental release: T333626. Completely fine to open this up and do backports now.

sbassett changed the task status from Open to In Progress.Apr 4 2023, 8:05 PM

sbassett triaged this task as Medium priority.

sbassett changed Author Affiliation from N/A to Wikimedia Communities.

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

sbassett changed Risk Rating from N/A to Medium.

Comment Actions

Unsure what else might need to be done before this can be marked as resolved (i.e. removing the patch on WMF systems), but the fix has been merged and backported to all supported versions that were vulnerable.

Comment Actions

Unsure what else might need to be done before this can be marked as resolved (i.e. removing the patch on WMF systems), but the fix has been merged and backported to all supported versions that were vulnerable.

We track Wikimedia production patches on another task and Release Engineering has a step in the train that detects when such patches should fall off. So I think this can be resolved for now.

Content licensed under Creative Commons Attribution-ShareAlike 4.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