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.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.