oss-sec mailing list archives
Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release
From: "Vincent Danen" <vdanen () redhat com>
Date: Fri, 28 Feb 2014 11:55:02 -0700
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_sanitizer 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." 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? 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
Attachment:
signature.asc
Description: OpenPGP digital signature
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)