This is a brief writeup on the security flaws fixed in the 1.23.7 (and 1.22.14/1.19.22) release.

<cross-domain-policy> mangling allows injection in API format=php

Bug: 71478 / T73478
Affected Versions: 1.10-1.23.7 (introduced in 28dc3ec8, fixed in e868f703 )
Type: Design flaw / CWE-502
CVE: CVE-2014-9277
Credit: PleaseStand

Background: Adobe flash (and Microsoft Silverlight) can make calls to and access information on domains other than where the .swf file is hosted if the target domain allows access with a cross-domain policy. The policy is expressed in xml, and can either be hosted in the sites default location (domain.com/cross-domain.xml), or a pointer to the policy file can be specified in the html embedding the plugin to point to another file on the target domain (domain.com/foo/bar/mypolicy.xml). This allowed anyone to add text that looked like a cross-domain policy to a wiki page, pass an action=raw url as the policy's url, and the flash plugin would be given full access to the wiki as the logged in user.

Adobe updated the flash plugin to always check for a master policy at cross-domain.xml in the domain root, so site owners could restrict hosting other policy files on the domain. But before they did this, MediaWiki took the precaution of changing any output containing "<cross-domain-policy>" to "<NOT-cross-domain-policy>".

preg_replace( '/\<\s*cross-domain-policy\s*\>/i', '<NOT-cross-domain-policy>', $s );

Issues: In addition to preventing an accurate representation of the wiki content if it happened to contain the string "<cross-domain-policy>" (T68776), PleaseStand recognized that because the length of the output string could change if whitespace was also removed. In php serialization (format=php in calls to the api), this could be abused to inject attacker controlled, serialized objects into the output, which could execute attacker-controlled code in api clients. This flaw has been present since the initial commit of the Flash mangling in 28dc3ec8 (MediaWiki 1.10). Although this code injection doesn't affect the server hosting the wiki, the issue was important to fix due to the number of bots using the php-format api on WMF wikis.

Fix: To prevent exploiting the specific issue, we throw an exception when the output contains <cross-domain-policy> in a php formatted api call, and mangling is enabled. Mangling can also be disabled with a config flag ($wgMangleFlashPolicy=false), if site administrators have deployed a cross-domain policy at their domain's root, which prevents policies from being defined on the wiki.

Users can change the content model of other users' user pages to CSS or JS

Bug: 70901 / T72901
Affected Versions: 1.21 - 1.23.7
Type: Design Flaw or CWE-862
CVE:
Credit: Jackmcbarn

Background: With the introduction of ContentHandler in MW 1.21, the type of content on a wiki page is determined by its content type instead of always being assumed to be wikitext. One of the features of ContentHandler (not deployed widely at the WMF) is ability to set an individual revision's content type through a db flag. When $wgContentHandlerUseDB is set, users can edit the content type of any revision through the api or hidden inputs in the web interface. If $wgContentHandlerUseDB is false, or a page doesn't have a content type set in the database, a default content type is determined based on the Title or namespace.

MediaWiki has historically treated a few subpages in the User's namespace special-- common.js/common.css (and other skin-specific .js/.css files). The name of the page was used to both access a user's customize js/css when rendering the page, and for access controls. With the introduction of ContentHandler, the content type is checked to be Javascript or CSS before rendering, and pages in the User namespace have special access controls when their content type is Javascript or CSS.

Issues: Jackmcbarn reported that on a wiki where $wgContentHandlerUseDB is set, if a user's common.js subpage (or any page where MediaWiki looks for customized css/js) is set to have a wikitext content type in the db, then the default access control checks allow any other user to edit that page. Since the user is able to edit the page, they were able to also edit the content type, to switch the page back to Javascript. When the user rendered a page, the attacker controlled javascript would be executed by the user.

Fix: The complete fix for this issue is complex, and would require a significant change to the architecture and functionality of MediaWiki. To allow public discussion about the issues around this change, a temporary fix was introduced in 9d7a0a1b to require a user right (editcontentmodel) to change the content type of a page. This prevents exploitation of the particular issue while the larger architecture issues are defined.

XSS in Special:ExpandTemplates when $wgRawHtml = true

Bug: 71111 / T73111
Affected Versions: Core 1.23.0-1.23.7
Type: CSRF leading to XSS
CVE: CVE-2014-9276
Credit: PleaseStand

Background: Parsed wikitext is assumed to be safe against XSS attacks. However, when $wgRawHtml is true this is not the case. But typically only trusted, authenticated users are allowed to add wikitext to a wiki that allows raw html.

Since MediaWiki 1.23 (or wikis with the ExpandTemplates extension), Special:ExpandTemplates allows a user to preview arbitrary wikitext.

Issue: Special:ExpandTemplates allows parsing arbitrary wikitext. Due to a failure to prevent CSRF attacks, an attacker could cause another user to parse arbitrary wikitext via csrf. When raw html is allowed, this allowed the attacker to inject javascript.

Fix: Adding an anti-CSRF token to the page prevents exploitation.

list=logevents in API shows type/action of suppressed and revdeleted log entries

Bug: 72222 / T74222
Affected Versions: 1.14-1.23.7
Type: Information disclosure
CVE:
Credit: Bawolff

Background: Since r46917, when a log is deleted with DELETED_ACTION, we still show the log's "action" in the api. The "action" in the API is a fixed, English string coming from MediaWiki code, and should not be user controlled. In the web UI, the localized message describing the action that generated the log entry is removed.

Issue: Because the deletion dialog for logs says "Hide action and target", and because the description of the action is hidden in the web interface, there might be situations where an action was suppressed, and the person suppressing would assume that someone wouldn't be able to see what kind of action generated the log message.

Fix: The action attribute was removed from the api result in 89b793b9, to enable a public discussion about this without potentially revealing sensitive information. The public discussion may determine that we want to leave the functionality as r46917 intended, and this patch will be reverted and the wording in the deletion dialog updated instead.