[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Re: YUI 2.x security issue regarding embedded SWF files -- or, How Not To Handle A Se
From:       cve-assign () mitre ! org
Date:       2012-11-16 17:22:44
Message-ID: 201211161722.qAGHMiRP017397 () linus ! mitre ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>Ok please use CVE-2012-5475 for this issue.

Here's an explanation of why MITRE didn't use CVE-2012-5475.

In 2010, YUI announced these three issues (see the
http://web.archive.org/web/20101028125444/http://yuilibrary.com/support/2.8.2/
URL):

  charts.swf XSS affecting 2.4.0 through 2.8.1
  uploader.swf XSS affecting 2.5.0 through 2.8.1
  swfstore.swf XSS affecting 2.8.0 through 2.8.1

These were assigned 3 CVEs to reflect the different affected versions:
CVE-2010-4207
CVE-2010-4208
CVE-2010-4209

The recent 2012 announcement at
http://yuilibrary.com/support/20121030-vulnerability/ had an
essentially identical pattern of affected versions. Because of this,
we published 3 CVEs for consistency with the 2010 outcome:

  CVE-2012-5881 charts.swf XSS affecting 2.4.0 through 2.9.0
  CVE-2012-5882 uploader.swf XSS affecting 2.5.0 through 2.9.0
  CVE-2012-5883 swfstore.swf XSS affecting 2.8.0 through 2.9.0

CVE-2012-5475 needed to be rejected in the process:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5475

We don't know why the original URL for the 2010 disclosure isn't
available with its original content. (Currently /support/2.8.2/ is a
301 redirect to the new
http://yuilibrary.com/support/20121030-vulnerability/ web page.) In
any case, the web.archive.org URL above has the 2010 data that
supports the 2010 abstraction choice.

We'll most likely update CVE-2010-4207, CVE-2010-4208, and
CVE-2010-4209 to delete the old

  CONFIRM:http://yuilibrary.com/support/2.8.2/

reference, and add the new

  CONFIRM:http://web.archive.org/web/20101028125444/http://yuilibrary.com/support/2.8.2/

reference. We think this is a good idea when a discloser's original
URL for one vulnerability is suddenly changed to only cover another
vulnerability. (We're much less certain that it's a good idea to
change to a web.archive.org URL, if one exists, in all of the many 404
and 403 error cases for other references in other CVEs.)

- -- 
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.11 (SunOS)

iQEcBAEBAgAGBQJQpnReAAoJEGvefgSNfHMd1MMH/iTfETyz8Sypj6swjHxIwtWy
m9Cv8/NgYcIydHDI3442Iyr7BbXKJ+duDH5v3kz30iznwcUnQRsqm13S4e68k3Xr
JBstDxN146GjRerJo21CU1kRxRBiMVtQ0AQYLmDzTaSRDZDQpvCCFEhVu6FJK8xj
wsuELgdY6ka5G/X7lERvSKjgOflhkEcSCK7ue51ow+LtO8tzwI88hCCNzBnVYxKj
bpyLO+P8uThucIqxsnYqCP1r3Xqi+mywmDOp2Q4o2Sh5x6rhK4UWlBkbdUmvlCKF
ql+HcJR88k220o684xI1uA7/dcR+baCKiPbnCb2M8yvDXrS/cfYqSXkKU1FGR/Q=
=fn2A
-----END PGP SIGNATURE-----
[prev in list] [next in list] [prev in thread] [next in thread]