[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <52579009.1010607@redhat.com>
Date: Thu, 10 Oct 2013 23:43:37 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com,
Assign a CVE Identifier <cve-assign@...re.org>
Subject: Re: RE: 2 CVE's to be rejected
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/10/2013 10:35 PM, Christey, Steven M. wrote:
>>> [cve-assign@...re] 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAEBAgAGBQJSV5AJAAoJEBYNRVNeJnmTABIQAKTkQQm3TRdgK0VxjxZmsCcD
YJUvPH5HC4d1qa/TDhrN6F33wZsdzL67JzPHlAXWh4jwlJiftEOKUQdec+6F61TS
ILRmsMNZOShoMtq3wTGmyxrMngFGuYTjnF3aiMkuyueyr/5A64Xs7bGnT8mIYwuk
sn10f0bmO0wkKCLKNnf7MQdWbqFWFKP9eM9PWP4qZolWMNDyhv/MzoAoHX/Zexsy
Nmdpk0L6yt6mgDu+w+k70ns3/kEhtquVB/FHiw6+5/BQGM927aZuEyAwzF8O4IJ/
Pow2ZXKKx99mIujuvraukxLfCniffIeNSefz9xpIuZW5bwBHh525U/hlGqHLWQUM
6v1pQ6ed77CfqoeBEcmzhTVDLyNx0a5wJHCpJ4J+azIk+pBcp2FWhx87vFYU6Tyj
WYUzg29af2TN1v7XZotcaU9gKrTv9TEjBNkMAypkqk3Z+XjA66QAiH22U9U9Ebrg
HtsGDgs3Wa6t/ezVETFMFWOKQnwftFeBObUA6DvZRNOR/XOsGqPZQVmqKdwUS7mR
fToJgcXeLA8Qd4MFnWkY5vaydVBvVRO35v1S2XP09Exws1RIexXvd7EDQql9Prd/
nUFjzchE60WJeS5kk7Nh540J4aOfUuInnsF9acoUxri0jld/uuNZUCm/BiOOTeNS
X/RSj8ke7D9YgB2PyXNS
=SKLO
-----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.
