oss-sec mailing list archives
Re: CVE requests for MediaWiki 1.26.1, 1.25.4, 1.24.5 and 1.23.12
From: cve-assign () mitre org
Date: Wed, 23 Dec 2015 14:06:58 -0500 (EST)
-----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-----
Current thread:
- CVE requests for MediaWiki 1.26.1, 1.25.4, 1.24.5 and 1.23.12 Chris Steipp (Dec 21)
- Re: CVE requests for MediaWiki 1.26.1, 1.25.4, 1.24.5 and 1.23.12 cve-assign (Dec 23)