Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12 release

["Vincent Danen" <vdanen () redhat com>]

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