Date: Wed, 23 Dec 2015 14:06:58 -0500 (EST) From: cve-assign@...re.org To: csteipp@...imedia.org Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE requests for MediaWiki 1.26.1, 1.25.4, 1.24.5 and 1.23.12 -----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' => '@...' ) 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-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ