Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 10 Oct 2013 23:43:37 -0600
From: Kurt Seifried <>
        Assign a CVE Identifier <>
Subject: Re: RE: 2 CVE's to be rejected

Hash: SHA1

On 10/10/2013 10:35 PM, Christey, Steven M. wrote:
>>> [] We would want this information even if the
>>> correct CVE ID still refers to an embargoed issue.
>> [Kurt] The duplicate issue is still embargoed, the other one is
>> also an embargoed issue.
> To be (hopefully) more clear, we do not need to "populate" the CVE
> description or references for the (still-valid) embargoed issue; we
> only want to refer to its ID from the REJECTed CVE.  That way, if
> for any reason the REJECTed CVE is used in public, there will be a
> clear link to the appropriate CVE.  We don't feel that the
> reference to the still-embargoed issue is an information leak of
> any sort, given that Red Hat is likely to be working on dozens of
> not-yet-disclosed vulnerabilities at any point in time, and you've
> already publicly stated that CVE-2013-1870 (or CVE-2013-4398?) is a
> dupe of *something*.
> While it's unusual to do a REJECT of one CVE and say that it's a
> duplicate of another CVE that's still not public and still shows up
> as RESERVED, this action still gives useful information to certain
> CVE consumers who rely on the CVE IDs to coordinate vulnerability
> information between diverse parties (which is, after all, CVE's
> primary goal).
> Similarly, while it's unusual to publicly claim a REJECT of one CVE
> because it's not a security issue, in the past we have supported
> various "private" REJECTs that occur when the original CVE
> requester determines that the issue is just a "bug" (or "feature")
> and not a vulnerability before the issue was ever published.  It
> doesn't seem like much of an information leak to know *that* a
> particular CVE ID was REJECTed because further research showed that
> the issue was not a vulnerability.
> As such, it doesn't seem like there would be any loss of
> privacy/secrecy if we knew which of (CVE-2013-1870 or
> CVE-2013-4398) was a duplicate [of some other CVE, whose ID would
> be nice to know even if the issue isn't public yet], and which of
> (CVE-2013-1870 or CVE-2013-4398) should be REJECTed because it's
> not a CVE-qualifying vulnerability at all.

Ah apologies, I misunderstood and thought that you needed details.
CVE-2013-1870 is a duplicate if CVE-2013-1869 (we thought it was two
separate issues, turned out to be a single issue).

> I recognize that we might not have sufficient insight into the
> situation at hand, so any clarification would be welcome.
> - Steve

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Version: GnuPG v1.4.14 (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.