Bug 2102868 (CVE-2022-34903)

Summary:	CVE-2022-34903 gpg: Signature spoofing via status line injection
Product:	[Other] Security Response	Reporter:	Sage McTaggart <amctagga>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	bcl, crypto-team, denis.arnaud_fedora, dhalasz, frantisek, jjelen, jkucera, kaycoth, pdelbell, rdieter, sthirugn, tm, vkrizan, vmugicag
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	gnupg-2.3.7	Doc Type:	If docs needed, set a value
Doc Text:	A vulnerability was found in GnuPG. This issue occurs due to an escape detection loop at the write_status_text_and_buffer() function in g10/cpr.c. This flaw allows a malicious actor to bypass access control.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-11-27 18:55:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2108443, 2108444, 2108445, 2108446, 2108447, 2108448, 2108449
Bug Blocks:	2102870

Description Sage McTaggart 2022-06-30 20:57:03 UTC

Post on oss-security: https://marc.info/?l=oss-security&m=165657063921408&w=2

Partial quote:
"""
After discovering that gpgv does not support
--exit-on-status-write-error, I decided to check if it handles write
errors on the status file descriptor properly.  I ultimately found that
while such errors are *not* handled properly, exploiting this flaw in
practice would likely be very difficult and unreliable.  However, in the
course of this research (and entirely accidentally), I found that if a
signature has a notation with a value of 8192 spaces, gpg will crash
while writing the notation's value to the status FD.  This turned out to
be a far more severe flaw, with consequences including the ability to
make a signature that will appear to be ultimately valid and made by a
key with any fingerprint one wishes.
"""

Comment 1 TEJ RATHI 2022-07-06 06:53:04 UTC

*** Bug 2103715 has been marked as a duplicate of this bug. ***

Comment 2 Sandipan Roy 2022-07-19 05:40:23 UTC

Created gnupg1 tracking bugs for this issue:

Affects: epel-all [bug 2108444]
Affects: fedora-all [bug 2108445]


Created gnupg2 tracking bugs for this issue:

Affects: fedora-all [bug 2108443]

Comment 5 Brian Lane 2022-07-19 19:16:03 UTC

FYI I can reproduce this using gpg2 and the examples in the email, but not with gpg1 due an unsupported algorithm in the signature. It looks like this is possible with a supported gpg1 signature, so I'm going to backport Werner's fix to g10/status.c which is where that code lives in the gpg1 codebase.

Comment 6 errata-xmlrpc 2022-09-13 09:46:09 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2022:6463 https://access.redhat.com/errata/RHSA-2022:6463

Comment 7 errata-xmlrpc 2022-09-20 14:06:34 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2022:6602 https://access.redhat.com/errata/RHSA-2022:6602

Comment 9 Product Security DevOps Team 2022-11-27 18:55:47 UTC

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2022-34903