Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 23 Dec 2015 14:06:58 -0500 (EST)
Subject: Re: CVE requests for MediaWiki 1.26.1, 1.25.4, 1.24.5 and 1.23.12

Hash: SHA256

> * (T117899) XSS from wikitext when $wgArticlePath='$1'. Internal review
> discovered an XSS vector when MediaWiki is configured with a non-standard
> configuration.
> <>

Use CVE-2015-8622.

> * (T119309) User::matchEditToken should use constant-time string
> comparison. Internal review discovered that tokens were being compared as
> strings, which could allow a timing attack. This should possibly have 2
> CVE's assigned,

> one for the original patch to use hash_equals in
> (released as
> part of MediaWiki 1.25, and backported to 1.24 and 1.23 as part of this
> patch)

Use CVE-2015-8623.

> one to fix T119309, related to the debugging statement.
> <>

Use CVE-2015-8624.

(Neither of the above two CVEs is the same as CVE-2015-6728, which
involves a different type of token.)

> * (T118032) Error thrown by VirtualRESTService when POST variable starts
> with '@'. Internal review discovered that MediaWiki was not sanitizing
> parameters passed to the curl library, which could cause curl to upload
> files from the webserver to an attacker.
> <>

> allows curl to try to be "helpful" by interpreting
> array( 'foo' => '@...' ) as a file upload.

Use CVE-2015-8625.


There is currently no CVE ID assigned for any related HHVM behavior.
It is conceivable that a CVE ID should exist if the
CURLOPT_SAFE_UPLOAD feature is required for HHVM's security policy,
or if it happens to be dangerously misleading to use the 5.6.99
version number but not address this curl concern.

> * (T115522) Passwords generated by User::randomPassword() may be shorter
> than $wgMinimalPasswordLength. MediaWiki user Frank R. Farmer reported that
> the password reset token could be shorter than the minimum required
> password length.
> <>

Use CVE-2015-8626.

> * (T97897) Incorrect parsing of IPs for global block. Wikimedia steward
> Vituzzu reported that blocking IP addresses with zero-padded octets
> resulted in a failure to block the IP address.
> <>

The security problem needing a CVE is that a partially privileged user
may falsely conclude that an address was successfully blocked, but the
address was actually not blocked. There is potentially a second
security problem in which a malicious partially privileged user could
have intentionally used extra zero characters to block a wide range of
legitimate editing ("this apparently blocked all newly registered
users"), leaving behind only a log entry that seemed to be about
blocking a single IP address. We are not sure whether this second
problem is relevant in the context of any MediaWiki threat model.

Use CVE-2015-8627.

> * (T109724) A combination of Special:MyPage redirects and pagecounts allows
> an external site to know the wikipedia login of an user. Wikimedia
> user Xavier Combelle reported a way to identify user, when detailed page
> view data is also released.
> <>

Our feeling is that the previous behavior should have a CVE because it
violates reasonable expectations about whether the set of visited URIs
contains, by itself, user identities. In the T109724 example, if a
client had visited a User:Xavier_Combelle page, no user identity is
potentially exposed because there is no discernible relationship
between the client and the name "Xavier Combelle." A visit to a
Special:MyPage page is an entirely different situation. Here, the
MediaWiki software is, in effect, combining the basic visited-URI
information with session information (the session belongs to Xavier
Combelle's account) in order to expand the scope of the visited-URI
concept. If that had been completely obvious (e.g., if MediaWiki had
always expressed visited URIs as something like
/Main_Page?logged_in_user=Xavier_Combelle and
/Special:MyPage?logged_in_user=Xavier_Combelle), then it wouldn't be a
vulnerability because people constructing reasonable analytics would
know to strip out the "logged_in_user=" fields. However, it's not
obvious at all: the server-side transformation of Special:MyPage to
User:Xavier_Combelle doesn't signal that an analytics implementation
needs to be concerned about an information leak. Also, we don't think
it can be considered a bug in any analytics product or site-specific
analytics methodology, because the information leak can also occur if
analytics are done informally by hand. For example, a site's owner
might announce something like "Our top five pages for 2015 were /ABC,
/DEF, /GHI, /JKL, and /User:Xavier_Combelle - not sure why that last
one was popular, but it was." Here, the actual situation could have
been the "if you can
convince the user to load special:mypage via say a hidden iframe, you
can just as easily convince them to load it 500 times" attack.

Use CVE-2015-8628.

- -- 
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

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ