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.
Description
Details
- Risk Rating
- Low
- Author Affiliation
- Wikimedia Communities
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Reedy | T292226 Release MediaWiki 1.35.5/1.36.3/1.37.1 | |||
Resolved | Reedy | T292227 Tracking bug for MediaWiki 1.35.5/1.36.3/1.37.1 | |||
Resolved | Security | • nnikkhoui | T292763 CVE-2021-44854: Rest API incorrectly publicly caches results from private wikis |
Event Timeline
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.
@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)
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.