[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Re: CVE requests for MediaWiki 1.26.1, 1.25.4, 1.24.5 and 1.23.12
From:       cve-assign () mitre ! org
Date:       2015-12-23 19:06:58
Message-ID: 20151223190658.1F7406FC009 () smtpvmsrv1 ! mitre ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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

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
> https://gerrit.wikimedia.org/r/#/c/156336/5/includes/User.php (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.
> <https://phabricator.wikimedia.org/T119309>

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.
> <https://phabricator.wikimedia.org/T118032>

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

Use CVE-2015-8625.


> https://github.com/facebook/hhvm/issues/6569

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.
> <https://phabricator.wikimedia.org/T115522>

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.
> <https://phabricator.wikimedia.org/T97897>

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.
> <https://phabricator.wikimedia.org/T109724>

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 https://phabricator.wikimedia.org/T109724#1637543 "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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJWevBCAAoJEL54rhJi8gl5xEEP/iecCWFKyUu1OktHZ9kTYsez
Rh/0CZKaADtQkqX+lz6RhB6LruS0lOnWdBB2yjTx5iveDgApn0gQ753pubqm3xBV
8EHdRwgN91X6iUWVDP777CcaDdPhQPinW2Az8sWI1i6walS7G2fst6JcWHM9vJ2W
Zu2BVUFPXvsFdUgPmLrJ0RzbrmNFsj0req/fapBEdQ6dUdKxYLQA3RSfiRz4ZMB5
D1t+Y3/c0MBnusmpS2bDoobfVIUuyqwB0SHOvEnlyBcgX3fgxIIdexFhh5d9FGgC
DH9/KtPZkU9Jtv1OiDLKib5/Nl1mjgZHj9kY7I6gUqEw2aw31tAMQGzqcDanIkJv
L0HXeIMvJu7XHoOWW8r3xunWKsdmqFXzJiLAX9Jnl5Dhlwsm3InI0myC8xdSLBPD
jW/XPWtSA41B8ZNyz1CGFxRcQH41tQ+LB6p0V4Fm2Kpq+9mdR4e4j2nACTt/IZey
/Fh93SZqIVfQ9XIkafvXVBS6a6hv6nGdhe+PTtUbG0xUAPaeacUuBTgscSdXzUmi
mTsNd2phjtH3TNB1aWue8OmFYeCp0Ru5NkzBAJDlsa6zCX+DJShN0QpM0ljp5eqq
nrtGytRfrmGSZ6zO/n7Y9M6Pgt9y7jpcrbY0OzMCIleHGvYMVe+q5K7hsbwQGyOZ
5w4zLSpVVCp1bY6bvHpN
=zTit
-----END PGP SIGNATURE-----
[prev in list] [next in list] [prev in thread] [next in thread]