Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 5 Nov 2012 20:56:15 +0000
From: "Christey, Steven M." <>
To: Kurt Seifried <>, ""
CC: Reed Loden <>, ""
Subject: RE: YUI 2.x security issue regarding embedded SWF
 files -- or, How Not To Handle A Security Disclosure

Sorry for the delay.

If a customer "owns" the systems or networks on which the software is installed, and/or is the entity who MUST take action to fix the issue, then it qualifies for a CVE.

If the fix for the issue is entirely in the hands of the vendor without any involvement by the consumer at all, then it does not get a CVE.  So, XSS on a custom web site, or a financial web site that exposes credentials, or a "typical" cloud-based offering, would generally not get a CVE.  (Note that this is a gap in the industry, as vulnerability databases in general don't cover "site-specific" or service-oriented issues.)

Based on the security-announcement-swf-vulnerability-in-yui-2 post, this requires users of YUI 2 to take certain actions for "Any project that hosts YUI 2 SWF files ...  on its own servers."  So, this qualifies for a CVE.

- Steve

-----Original Message-----
From: Kurt Seifried [] 
Sent: Monday, November 05, 2012 3:49 PM
Cc: Reed Loden; Christey, Steven M.;
Subject: Re: [oss-security] YUI 2.x security issue regarding embedded SWF files -- or, How Not To Handle A Security Disclosure

Hash: SHA1

On 11/04/2012 05:13 PM, Kurt Seifried wrote:
> On 11/04/2012 01:34 PM, Reed Loden wrote:
>> I haven't seen this posted at all, but it seems there's some 
>> (major?) security issue regarding the SWF files embedded in YUI
>> 2. The YUI team has published a blog post regarding this problem 
>> asking users to e-mail them for details.
>>  The comments are a great read. Ryan Grove (former Yahoo! and
>> YUI core team guy) hits the point on the head regarding
>> disclosure handling of the issue. Apparently, some
>> people/companies have already been notified directly weeks ago,
>> and this is how the YUI team is continuing the disclosure process
>> by just asking projects to e-mail them instead of just releasing
>> the fix to the public at this stage. :/
>> Might want to go ahead and get a CVE assigned to whatever this 
>> issue is, and hope more details come out of this soon so YUI 2 
>> users can actually get patched instead of having to request
>> access to the fix...
>> ~reed (speaking only for himself)
> Have any CVE's been issued for this issue? I can't find any. More
> to the point does this kind of issue (is it a service strictly?)
> even get a CVE? Steve?

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

Also can follow their disclosure policy listed
at and disclose the problem:

Disclosure of Security Issues

If you've discovered a security flaw in one of our products, please
contact us. Expect to receive an acknowledgement quickly with the best
way to track your report's status. You'll have a direct contact at YUI
while we investigate.

Since issues have varying impact, we ask for your patience while we
make sure everyone who uses our products is protected. We will
disclose a problem once it's confirmed and a resolution is available.
If a fix is required, our release will credit you for your discovery.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1.4.12 (GNU/Linux)


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.