Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALDM2Hc9XdQh0xjB1SKwMofRnTS2ORubMi3QZ0=Yo0NObnuq4A@mail.gmail.com>
Date: Wed, 10 Jul 2024 08:48:33 -0600
From: Nick Tait <ntait@...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

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.