Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue,  7 Apr 2015 03:34:12 -0400 (EDT)
Subject: Re: CVE request: MediaWiki 1.24.2/1.23.9/1.19.24

Hash: SHA1

> * iSEC Partners discovered a way to circumvent the SVG MIME blacklist for
> embedded resources (iSEC-WMF1214-11). This allowed an attacker to embed
> JavaScript in the SVG. The issue was additionally identified by Mario
> Heiderich / Cure53. MIME types are now whitelisted.

Use CVE-2015-2931 for this issue involving an incomplete list of
disallowed MIME types for data: URIs (the application/xml type wasn't
in this list). In other words, CVE-2015-2931 does not refer more
generally to the desirability of the "MIME types are now whitelisted"

> * MediaWiki user Bawolff pointed out that the SVG filter to prevent
> injecting JavaScript using animate elements was incorrect.

Use CVE-2015-2932 for this issue involving an incomplete list of
dangerous parts of HTML5. (The list is supposed to include all uses of
'animate attributename="xlink:href"' in SVG documents.)

> * MediaWiki user Bawolff reported a stored XSS vulnerability due to the way
> attributes were expanded in MediaWiki's Html class, in combination with
> LanguageConverter substitutions.

Use CVE-2015-2933 for this XSS issue.

Also, this part of T73394 seems potentially interesting although it is
apparently neither a MediaWiki bug nor a PHP bug:
  preg_match() silently returns false on limit exhaustion

In other words, if a PHP application uses
"ini_set('pcre.recursion_limit'" and does not properly handle the
preg_match return value, then a hard-to-find XSS vulnerability might

> * Internal review discovered that MediaWiki's SVG filtering could be
> bypassed with entity encoding under the Zend interpreter. This could be
> used to inject JavaScript. This issue was also discovered by Mario Gomes /
> Beyond Security.

Use CVE-2015-2934 for this interaction issue in which (roughly
speaking) secure operation of MediaWiki had been relying on a libxml
behavior that was removed for unrelated security reasons. (In other
words, it's apparently an usual type of vulnerability whose avoidance
requires studying all "improvements" in new releases of library code,
and determining whether any of them have unintended adverse

> * iSEC Partners discovered a way to bypass the style filtering for SVG
> files (iSEC-WMF1214-3) to load external resource. This could violate the
> anonymity of users viewing the SVG.

Use CVE-2015-2935 for this issue of information leaks observable in
log files on an attacker-controlled web server. This issue exists
because of an incomplete fix for CVE-2014-7199.

> * Internal review and iSEC Partners discovered (iSEC-WMF1214-1) that
> MediaWiki versions using PBKDF2 for password hashing (the default since
> 1.24) are vulnerable to DoS attacks using extremely long passwords.

Use CVE-2015-2936 for this vulnerability with a CPU consumption impact.

> * Internal review found that MediaWiki is vulnerable to "Quadratic Blowup"
> DoS attacks, under both HHVM and Zend PHP.

Use CVE-2015-2937. This is a quadratic issue and isn't the same as the
CVE-2015-2942 exponential issue affecting only HHVM (see below).

> * iSEC Partners reported that the MediaWiki feature allowing a user to
> preview another user's custom JavaScript could be abused for privilege
> escalation (iSEC-WMF1214-10). This feature has been removed.

Use CVE-2015-2938 for this XSS issue.

> * Extension:Scribunto - MediaWiki user Jackmcbarn discovered that function
> names were sanitized in Lua error backtraces, which could lead to XSS.

Use CVE-2015-2939 for this XSS issue. In the above quoted text, "were
sanitized" should be "were not sanitized" instead.

> * Extension:CheckUser - iSEC Partners discovered that the CheckUser
> extension did not prevent CSRF attacks on the form allowing checkusers to
> look up sensitive information about other users (iSEC-WMF1214-6). Since the
> use of CheckUser is logged, the CSRF could be abused to defame a trusted
> user or flood the logs with noise.

For purposes of CVE, we'll accept reports from a software's author
stating that there is a CSRF vulnerability for a request to read data.
Use CVE-2015-2940. This does not mean that similar reports from
arbitrary researchers about arbitrary products would have CVE IDs
assigned. For many products, the implied security policy does not
include a CSRF protection mechanism that prevents all
undesirable/confusing log entries.

> I'm not sure if CVE's are assigned for specific runtime
> configurations? For MediaWiki, we say that HHVM support is experimental,
> although we do run Wikipedia on it.

There isn't a general rule that CVE IDs are assigned for arbitrary
unsupported deployments of a product. Our impression is that users may
realistically decide that the HHVM support is "complete enough" for
their purposes. Also, in some cases, HHVM support is referenced or
documented in places that don't directly discuss the experimental
nature, such as on the and pages. So, here, we
do want to assign CVE IDs applicable only to HHVM deployments.

> * iSEC Partners discovered a XSS vulnerability in the way api errors were
> reflected under HHVM versions before 3.6.1 (iSEC-WMF1214-8). MediaWiki now
> detects and mitigates this issue on older versions of HHVM.

It seems that the major concern here is the HHVM vulnerability fixed
by the
commit. Use CVE-2014-9714 for that HHVM vulnerability.

As far as we can tell, T85851 is recommending,unified
as a vulnerability fix for MediaWiki deployments that use an older
version of HHVM. Use CVE-2015-2941 for this MediaWiki vulnerability in
which unsafe calls to wddx_serialize_value can occur.

> * iSEC Partners discovered that MediaWiki's SVG and XMP parsing running
> under HHVM was susceptible to "Billion Laughs" DoS attacks
> (iSEC-WMF1214-13).

Use CVE-2015-2942 for this exponential issue, which is different from
the CVE-2015-2937 quadratic issue mentioned above.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.