[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20151223190658.1F7406FC009@smtpvmsrv1.mitre.org>
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.
