Date: Fri, 28 Feb 2014 11:55:02 -0700 From: "Vincent Danen" <vdanen@...hat.com> To: oss-security@...ts.openwall.com Cc: mmcallis@...hat.com, cve-assign@...re.org, "Markus Glaser" <glaser@...lowelt.biz> Subject: Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release 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@...re.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 Download attachment "signature.asc" of type "application/pgp-signature" (711 bytes)
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