Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 27 Aug 2015 15:33:51 -0400 (EDT)
Subject: Re: CVE Request: MediaWiki 1.25.2, 1.24.3, 1.23.10

Hash: SHA256

> * Internal review discovered that Special:DeletedContributions did not
> properly protect the IP of autoblocked users. This fix makes the
> functionality of Special:DeletedContributions consistent with
> Special:Contributions and Special:BlockList.
> <>

The DESCRIPTION section of T106893 refers to a similar issue that
existed in other code until 2013. As far as we can tell, both issues
have security relevance for the same reason (although the first issue
was debated at the time). So, we think it will be best to use
CVE-2015-6727 for the issue fixed in the
commit, and CVE-2013-7444 for the issue fixed in the

> * Internal review discovered that watchlist anti-csrf tokens were not being
> compared in constant time, which could allow various timing attacks. This
> could allow an attacker to modify a user's watchlist via csrf.
> <>

Use CVE-2015-6728.

> * John Menerick reported that MediaWiki's thumb.php failed to sanitize
> various error messages, resulting in xss.
> <>

Based on the T97391 "Apr 28 2015, 5:58 PM" comment describing both
"Confirmed the rel404 issue" and "ForeignAPI images also have an xss"
vectors, it appears that the original John Menerick report was about
"unvalidated or sanitized parameters are pulled from the client's
request" and that the f parameter wasn't necessarily known to be
exploitable when that report was written. (Maybe this isn't accurate
because the "attached image" in the original report is apparently
unavailable.) In any case, use CVE-2015-6729 for the John Menerick XSS
report, and use CVE-2015-6730 for the internal XSS discoveries.

> * Extension:SemanticForms - MediaWiki user Grunny discovered multiple
> reflected xss vectors in SemanticForms. Further internal review discovered
> and fixed other reflected and stored xss vectors.
> <>
> <>
> <>

Use CVE-2015-6731 for the Grunny XSS report, and use CVE-2015-6732 for
the internal XSS discoveries.

There is currently no CVE ID for the "The Special:CreateForm post to
add the template doesn't check the csrf token, so it can be submitted
for a user via csrf" statement in the T103761 DESCRIPTION section. We
aren't sure about this, but we think that a CSRF token check there is
not thought to be required. If a CSRF token check there is thought to
be required, then another CVE ID can be assigned.

> * Extension:SyntaxHighlight_GeSHi - xss and potential DoS vectors. Internal
> review discovered that the contib directory for GeSHi was re-included in
> MediaWiki 1.25. Some scripts could be potentially be used for DoS, and DAU
> Huy Ngoc discovered an xss vector. All contrib scripts have been removed.
> <>

There are multiple options with which this topic could be covered in
CVE, e.g.,

  1. It is a single integration-policy error. In other words, the
     policy is that Extension:SyntaxHighlight_GeSHi may have an update
     at any time from the upstream GeSHi source code, but the contrib
     directory must be excluded. A person who did an update did not
     follow that policy.

  2. The problems with using the upstream contrib directory within
     MediaWiki need to be considered individually.

We're using option 2.

"Some scripts could be potentially be used for DoS" is not really
enough information, because distinct types of DoS can't always be
combined into one CVE ID. We think the only known DoS problem is
resource consumption from otherwise correct algorithms, as mentioned
at with "GeSHi aims to do this all as
quickly as possible. Many customisable features of GeSHi facilitate
speed increases, and you can easily find a balance between the amount
of highlighting done and the speed in which it is done." Use
CVE-2015-6733 for this type of resource-consumption DoS, which has
security relevance within the MediaWiki product.

Use CVE-2015-6734 for the cssgen.php keywords-1 XSS. (Although not
directly related to CVE assignment, it's possible that that XSS hasn't
been reported upstream because it's not listed on the

> * Extension:TimedMediaHandler - User:McZusatz reported that resetting
> transcodes deleted the transcode without creating a new one, which could be
> used for vandalism or potentially DoS.
> <>

Use CVE-2015-6735.

> * Extension:Quiz - Internal review discovered that Quiz did not properly
> escape regex metacharacters in a user controlled regular expression,
> enabling a DoS vector.
> <>

Use CVE-2015-6736.

> * Extension:Widgets - MediaWiki developer Majr reported a potential HTML
> injection (xss) vector.
> <>

Use CVE-2015-6737. We think that the primary vulnerability is that the
approach to integrity protection is wrong, and that the HTML injection
is resultant from this. In any case, we think that only one CVE ID is
needed for T88964.

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


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.