oss-sec mailing list archives
Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release
From: Chris Steipp <csteipp () wikimedia org>
Date: Fri, 28 Feb 2014 11:46:24 -0800
I'm from the foundation, and I'm on the list. Let me try to answer. On Feb 28, 2014 10:55 AM, "Vincent Danen" <vdanen () redhat com> wrote:
Seems odd to be asking these questions without asking someone from the
MediaWiki team involved (I doubt they are subscribed to oss-sec). Given that Murray just posting what was written by upstream and even asked "if CVE worthy" I doubt he has the answers you're looking for. =)
I've cc'd Markus Glaser to this as he sent out the notification to the
mediawiki-announce list so he may have the insight you're looking for.
On 02/28/2014, at 11:26 AM, cve-assign () mitre org wrote:Some of this seems straightforward and we will send CVE assignments a little later. Our first question is about the UploadBase.php diff in:
https://gerrit.wikimedia.org/r/#/q/7d923a6b53f7fbcb0cbc3a19797d741bf6f440eb,n,z
Our first thought is that it might be best to have separate CVEs for "Disallow uploading non-whitelisted namespaces" and "disallow iframe elements" because they are distinct types of problems. The first one seems similar to what is discussed in: http://en.wikipedia.org/wiki/User:Aarchiba/SVG_sanitize of The first CVE would, roughly, have a root cause of "does not recognize that a trust relationship with a specific external site is reasonably required for use of a namespace." The second CVE would, roughly, have a root cause of "does not block IFRAME elements."
With the whitelisted set of namespaces, iirc, iframe doesn't have a valid definition. It was the combination of the iframe and the namespace that allowed the js to execute.
Does anyone have an opposing view: for example, that adding the hardcoded $validNamespaces list can't be interpreted as a "normal" vulnerability fix? Across all products, adding a list of off-site URLs maintained by various third parties is rarely the essence of a security patch. (As a side issue, SVG_sanitizer allows http://www.w3.org/XML/1998/namespace but the patched UploadBase.php does not.) Our second question is about https://bugzilla.wikimedia.org/show_bug.cgi?id=61346 Comment 9. Do all valid tokens have the same length, and thus an attacker (if he looked at the source code) would already know that the wrong-length attempts would always fail?
Yes, the token length has been defined by a constant in the code (USER_TOKEN_LENGTH) for as far back as I've traced it (Tim's 2004 commit).
If not, a separate CVE would be needed on the basis of different affected versions. (This question is only about MediaWiki as shipped. If a system administrator would need to modify the source code to use a different length, and an attacker could detect that more easily because of 'strlen( $answer ) !== strlen( $test )' tests, that doesn't qualify for a CVE.) - -- 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 ]-- Vincent Danen / Red Hat Security Response Team
Current thread:
- CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release Murray McAllister (Feb 27)
- Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release cve-assign (Feb 28)
- Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release Vincent Danen (Feb 28)
- Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release Chris Steipp (Feb 28)
- Re: Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release Simon McVittie (Feb 28)
- Re: Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release Chris Steipp (Feb 28)
- Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release Vincent Danen (Feb 28)
- Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release cve-assign (Mar 01)
- Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release cve-assign (Feb 28)