Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Feb 2014 11:55:02 -0700
From: "Vincent Danen" <>
        "Markus Glaser" <>
Subject: Re: CVE requests: MediaWiki 1.22.3, 1.21.6 and 1.19.12

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, 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:
> 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:
> 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
> but the patched UploadBase.php
> does not.)
> Our second question is about
> 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 ]

Vincent Danen / Red Hat Security Response Team
Download attachment "signature.asc" of type "application/pgp-signature" (711 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ