[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEFCzXUwgt1dcoDvcjKEJ9Tj-kiFpQ0u_GQT14BcztXWiRgrSw@mail.gmail.com>
Date: Wed, 10 Jul 2024 11:06:05 -0400
From: Pete Allor <pallor@...hat.com>
To: oss-security@...ts.openwall.com
Cc: Qualys Security Advisory <qsa@...lys.com>
Subject: Re: CVE-2024-6387: RCE in OpenSSH's server, on
glibc-based Linux systems
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 secalert@...hat.com and we
will work on it.
Pete
On Wed, Jul 10, 2024 at 10:57 AM Nick Tait <ntait@...hat.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 secalert@...hat.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 <solar@...nwall.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
> >
> >
>
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.
