Follow @Openwall on Twitter for new release announcements and other news
[<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

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.