Bug 2102868 (CVE-2022-34903) - CVE-2022-34903 gpg: Signature spoofing via status line injection
Summary: CVE-2022-34903 gpg: Signature spoofing via status line injection
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2022-34903
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
: 2103715 (view as bug list)
Depends On: 2108449 2108443 2108444 2108445 2108446 2108447 2108448
Blocks: 2102870
TreeView+ depends on / blocked
 
Reported: 2022-06-30 20:57 UTC by Sage McTaggart
Modified: 2022-11-27 18:55 UTC (History)
14 users (show)

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.
Clone Of:
Environment:
Last Closed: 2022-11-27 18:55:49 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2022:6463 0 None None None 2022-09-13 09:46:11 UTC
Red Hat Product Errata RHSA-2022:6602 0 None None None 2022-09-20 14:06:36 UTC

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


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