Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 27 Jun 2014 17:35:52 -0400 (EDT)
Subject: Re: MediaWiki releases 1.19.17, 1.21.11, 1.22.8 and 1.23.1

Hash: SHA1

> I didn't get a CVE in advance because I thought this was likely a
> hardening fix.


We generally can't assign a CVE ID for a case where a vendor decides
to add speculative restrictions in a tradeoff against
functionality/usability. (Admittedly, the new restrictions here seem
reasonable and had a careful cost/benefit analysis by the vendor.)

Our understanding is that:

  1. in both the old and new code, if someone uploads a filename.svg
     file, then the MediaWiki product creates HTML code with,
     basically, <a href="filename.svg"><img src="filename.svg.png"></a>

     where filename.svg.png is in PNG format and contains PNG data from
     the SVG file. In other words, a visitor can navigate among
     articles without encountering inline SVG content. Also, both the
     .svg file and the .svg.png file are normally hosted in a domain
     controlled by the operator of the MediaWiki instance.

  2. in the old code, people could upload an SVG file that loads
     content from other domains

  3. in the new code, people can't upload an SVG file that loads
     content from other domains

Here, 3 is a tradeoff because an SVG file that's very relevant to an
article might be one that loads external content, and the uploader
might not be capable of changing that. (Among other issues, there
could be license concerns.)

The rationale for 3 seems to be:

  A. inline SVG content might become desirable in future releases
     of the MediaWiki product, with inline external-domain content
     remaining undesirable


  B. there might be current third-party code that renders articles
     (obtained from a MediaWiki instance) with inline SVG instead of
     inline PNG

Rationale A doesn't seem to qualify for a CVE because there's no
inline-content concern in the current version. The tradeoff is being
made in anticipation of future product directions.

Rationale B is arguably a security problem because it sends
article-visit information to operators of external web sites,
something that apparently hasn't been occurring on many well-known
MediaWiki instances in the past. (For example, for some of these
instances, a visitor might expect that basic article visits would send
requests only to * servers.) It'd be reasonable for a
third-party vendor to make an announcement such as "this fixes the
vulnerability of leaking article-visit information to arbitrary web
servers, where we were intending to restrict that to a small set of
servers." However, no such third-party vendor is known.

> From:
> Date: Thu, 26 Jun 2014 19:32:38 +0200
> This is probably another very fundamental question of CVE assignment,
> but IMHO: "We're not sure if this can be exploited" is certainly worth
> a CVE.
> I'd suggest that one gets assigned.

We agree that, if the old code enabled an exploit with respect to the
security policy of any third-party product, then a CVE ID could be
assigned. However, we first would need to know what product is
affected before assigning the CVE ID.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.