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 > >
