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

[Chris Steipp <csteipp () wikimedia org>]

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