Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240709224923.GA17147@openwall.com>
Date: Wed, 10 Jul 2024 00:49:23 +0200
From: Solar Designer <solar@...nwall.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

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.