Other records for the same CVE can also be posted to CVE.org and listed on their website with a link for completeness.
Under CVE rules, Red Hat can only assign a CVE for issues within our scope, which for most CNAs means their software. RH has on occasion, provided a CVE for upstream projects which are not covered by another CNA. That is really about a coordination point between multiple parties. When considering becoming a CNA, it should not be for an occasional CVE so becoming a CNA should be considered if you have a good number per year AND you have the people to do that work regularly. I can offer that if you wish for Red Hat to add to this record, then we would be glad to assist. Please send a DM to secal...@redhat.com and we will work on it. Pete On Wed, Jul 10, 2024 at 10:57 AM Nick Tait <nt...@redhat.com> wrote: > Damian, in general when there is incorrect data on any of Red Hat's CVE > pages the best place to request a fix is secal...@redhat.com. > > In this case we are paying attention to this mailing list and have > incorporated some suggestions. I can help address any remaining cleanups. > > Has OpenSSH ever considered becoming a CNA? > > ~Nick > > On Tue, Jul 9, 2024 at 4:51 PM Solar Designer <so...@openwall.com> wrote: > > > On Tue, Jul 09, 2024 at 09:52:58AM +1000, Damien Miller wrote: > > > On Mon, 8 Jul 2024, Solar Designer wrote: > > > > Today is the coordinated release date to publicly disclose a related > > > > issue I found during review of Qualys' findings, with further > analysis > > > > by Qualys. My summary is: > > > > > > > > CVE-2024-6409: OpenSSH: Possible remote code execution in privsep > child > > > > due to a race condition in signal handling > > > > > > As an aside, who wrote the text of > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-6409 ? > > > > I don't know for sure, but I guess someone from Red Hat did since the > > CVE was assigned by them as a CNA. Also, the description is the same as > > what's in Red Hat Bugzilla. > > > > > It's disappointing that this CVE states that this is a vulnerability > > > in OpenSSH sshd, and fails to make clear that this only affects Redhat > > > versions and users of their downstream patch. > > > > This was in the title, just not in the description. And now I see I did > > it the other way around in my oss-security posting - should have been > > more careful to include this information in both the suggested title and > > in the description - sorry about that. Meanwhile, looks like the > > CVE-2024-6409 record has been updated today, perhaps in response to your > > message, and now says Red Hat Enterprise Linux 9 also in the description. > > > > > This follows another critical failure to properly issue CVEs for > OpenSSH: > > > CVE-2024-6387 only lists CPEs for Redhat systems as affected (see the > > > JSON dump of the entry: https://cveawg.mitre.org/api/cve/CVE-2024-6387 > ) > > > > The current revision (also updated today) starts with: > > > > "affected": [ > > { > > "repo": "https://anongit.mindrot.org/openssh.git";, > > "versions": [ > > { > > "status": "affected", > > "version": "8.5p1", > > "versionType": "custom", > > "lessThanOrEqual": "9.7p1" > > } > > ], > > "packageName": "OpenSSH", > > "collectionURL": "https://www.openssh.com/";, > > "defaultStatus": "unaffected" > > }, > > > > and only then proceeds to give CPEs for Red Hat products. > > > > > This means that anyone using automation that consumes CVEs for > detecting > > > vulnerabilities will be left exposed. > > > > Does the above look good enough now, or should there also be a CPE for > > upstream OpenSSH? > > > > > Moreover, the explanatory text for CVE-2024-6387 is also extremely > > lacking. > > > It fails to explain the consequence of the vulnerability (unauth RCE) > and > > > just talks about mechanism. > > > > This is still the case, and this CVE was also assigned by Red Hat (in > > response to requests by Qualys and me in the distros list discussion), > > and the description is also the same as in Red Hat Bugzilla, so should > > probably be first improved in a database Red Hat uses internally. > > > > > I don't know if it's in anyone on this list's ability to get these > > > fixed, but IMO they are serious failures of the CVE process that make > > > it near-useless for consumers of this information. > > > > Apparently, someone in here noticed and started making edits. > > > > Alexander > > > > >
