Bug 2315719 (CVE-2024-9355) - CVE-2024-9355 golang-fips: Golang FIPS zeroed buffer [NEEDINFO]
Summary: CVE-2024-9355 golang-fips: Golang FIPS zeroed buffer
Keywords:
Status: NEW
Alias: CVE-2024-9355
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-09-30 17:59 UTC by OSIDB Bzimport
Modified: 2024-10-09 23:28 UTC (History)
81 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A vulnerability was found in Golang FIPS OpenSSL. This flaw allows a malicious user to randomly cause an uninitialized buffer length variable with a zeroed buffer to be returned in FIPS mode. It may also be possible to force a false positive match between non-equal hashes when comparing a trusted computed hmac sum to an untrusted input sum if an attacker can send a zeroed buffer in place of a pre-computed sum.  It is also possible to force a derived key to be all zeros instead of an unpredictable value.  This may have follow-on implications for the Go TLS stack.
Clone Of:
Environment:
Last Closed:
Embargoed:
debarshir: needinfo? (bzimport)
debarshir: needinfo? (pdelbell)


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2024:7521 0 None None None 2024-10-02 14:47:36 UTC
Red Hat Product Errata RHBA-2024:7565 0 None None None 2024-10-03 12:43:23 UTC
Red Hat Product Errata RHBA-2024:7571 0 None None None 2024-10-03 01:28:47 UTC
Red Hat Product Errata RHSA-2024:7502 0 None None None 2024-10-02 11:42:08 UTC
Red Hat Product Errata RHSA-2024:7550 0 None None None 2024-10-02 18:20:12 UTC

Description OSIDB Bzimport 2024-09-30 17:59:28 UTC
Binaries built with golang-1.21.13-3.el9_4 and
golang-1.21.13-2.module+el8.10.0+22329+6cd5c9c6 may
intermittently return a zeroed buffer from (*boringHMAC).Sum() in FIPS mode due to an uninitialized buffer length variable in the CGO bindings.  This bug occurs randomly based on the stack layout at the time of the function call.  It is not vulnerable to eg. buffer overflow attack because the underlying openssl routine checks the bounds of the buffer before writing
to it.  However, it may be possible to force a false positive match between non-equal hashes when comparing a trusted computed hmac sum to an untrusted input sum if an attacker is able to send a zeroed buffer in place of a pre-computed sum.  It is also possible to force a derived key to be all zeros instead of an unpredictable value.  This may have follow-on implications for the Go TLS stack.

Comment 1 Debarshi Ray 2024-10-01 23:50:34 UTC
(In reply to OSIDB Bzimport from comment #0)
> Binaries built with golang-1.21.13-3.el9_4 and
> golang-1.21.13-2.module+el8.10.0+22329+6cd5c9c6 may
> intermittently return a zeroed buffer from (*boringHMAC).Sum() in FIPS mode
> due to an uninitialized buffer length variable in the CGO bindings.

What do these NEVRA numbers really mean?  Does a Go binary have to be compiled with one of these exact NEVRAs to have this bug?  Or older?  Or newer?

Comment 3 errata-xmlrpc 2024-10-02 11:42:04 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2024:7502 https://access.redhat.com/errata/RHSA-2024:7502

Comment 4 errata-xmlrpc 2024-10-02 18:20:07 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2024:7550 https://access.redhat.com/errata/RHSA-2024:7550

Comment 5 Debarshi Ray 2024-10-09 23:28:26 UTC
I am still looking for someone who can answer comment 1


Note You need to log in before you can comment on or make changes to this bug.