[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <201406272136.s5RLZqBg010364@linus.mitre.org>
Date: Fri, 27 Jun 2014 17:35:52 -0400 (EDT)
From: cve-assign@...re.org
To: csteipp@...imedia.org
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: MediaWiki releases 1.19.17, 1.21.11, 1.22.8 and 1.23.1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> I didn't get a CVE in advance because I thought this was likely a
> hardening fix.
> https://bugzilla.wikimedia.org/show_bug.cgi?id=65839#c29
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
and
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 *.wikimedia.org 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: hanno@...eck.de
> 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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJTreLhAAoJEKllVAevmvms1vsH/2q+76Af858ef5/imRmLpag1
18HgNQuDjMuzoOmkydpH4TYHnrPAm2Cj9Sw4k/5aWX+E7ufo3cImPOG5VsBtKKjA
58RUbsC1Tn5/C3+NdNZr4MmFC4FQN+SDeDw9s6reoPJdVoPKg19ymE+DqCN8mxo4
M0MVFWsu6KJumr4EAZcduDV23LuzblxI98ibxBgpiFzLAF/ASQabeT4xQoeELnud
nEwqqqEiuVeEAXOM3lNfrZQVRmGFzIjWrTVBm1f40jYqL3PbADxxTdEJX9AAZOI0
TYB9bqJ513Iva5+dnKOiKM3TO4Jje+7kjsrIrXub4O/+t+8izwN2FmIEjwYDNwU=
=2xMI
-----END PGP SIGNATURE-----
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.
