Page MenuHomePhabricator

CVE-2021-44854: Rest API incorrectly publicly caches results from private wikis
Closed, ResolvedPublicSecurity

Description

Go to https://office.wikimedia.org logged out and start typing "s" or "w" in the search bar, it will start autocompleting the query with a dropdown menu of page titles. This means unauthorized users could access potentially confidential data if that data is included in the page title.

Event Timeline

Reedy triaged this task as High priority.EditedOct 7 2021, 5:23 PM
Reedy added a subscriber: Reedy.

Thanks for the report!

I don't think this is really a new vector bug, beyond it being the one exposing it. It looks like it may be a caching issue, not necessarily specifically a MediaWiki-REST-API bug, though it could be the REST API setting/sending incorrect cache headers.

If I visit https://office.wikimedia.org/w/rest.php/v1/search/title?q=test&limit=10 I get {"error":"rest-read-denied","httpCode":403,"httpReason":"Forbidden"} which looks right.

Whereas a search for some letters is very likely cached, and just served to anyone?

Config seems fine:
https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L15169-L15172

$ mwscript shell.php --wiki=officewiki
...
>>> var_dump( $wgEnableMWSuggest );
>>> bool(false)

This isn't great, but I'm not sure it would be much more than a low risk right now. Just trying out various search strings like "password", "budget", "user", etc, I'm not seeing any serious information disclosure, at least not for officewiki. If there are any specific search strings that result in serious privacy leaks, please let us know either on this task or by disclosing them directly to the Security-Team.

sbassett changed Author Affiliation from N/A to Wikimedia Communities.Oct 8 2021, 4:11 PM
sbassett changed Risk Rating from N/A to Low.

@nnikkhoui why was this patched publicly rather than handled as a security bug? AFAICT (I skimmed very quickly) released versions of MediaWiki are also vulnerable to this kind of cache poisoning/leak.

@Legoktm oh yikes, it wasn't handled as a security bug for the sole reason that this was my first one and had not realized there was a specific way to handle those in Gerrit (I actually do recall @Pchelolo mentioned something but it slipped my mind before i uploaded -_-) will educate myself on how for future security bugs.
I think you are right, basically anything that uses that search endpoint (which i think(?) is just new Vector with the vue.js search widget)

daniel added a subscriber: daniel.

Looks like this is fixed

Looks like this is fixed

Yes. This might get a mention within the next security release (it's tracked on the bug) but everything else has already been fixed and disclosed via gerrit, so no need to keep this task private.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".Nov 12 2021, 9:23 PM
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett moved this task from Watching to Our Part Is Done on the Security-Team board.
Reedy renamed this task from Private wikis with new vector return autocomplete search results to Rest API incorrectly publicly caches results from private wikis.Dec 10 2021, 5:58 PM
Reedy renamed this task from Rest API incorrectly publicly caches results from private wikis to CVE-2021-44854: Rest API incorrectly publicly caches results from private wikis.Dec 15 2021, 7:52 PM