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.