gpg.fail talk flags gpgsm debug RCE and un-CVEd libgcrypt PSS fix

Authors of the gpg.fail research have published a retrospective that surfaces two further problems in the GnuPG stack: a format-string flaw in gpgsm they present as remote code execution, and an already-patched libgcrypt RSASSA-PSS bug they say still lacks a CVE for distributors to track.

Lexi Groves, who gave the talk, called the gpgsm case an unreported zero-day. With X.509 debugging enabled, certificate import treated attacker-controlled DER data as a printf format string. Groves described using %n for memory writes, packing multiple certificates into one PEM to re-enter and defeat ASLR, and a polyglot certificate that simply execs itself. The path needs an explicit debug option and an import of untrusted input, so everyday production use is not the obvious target.

GnuPG maintainer Werner Koch said the bad logging call has existed in versions after 2.2 whenever X.509 debug is on, and that the published sample produced garbled stderr or a crash rather than a clear exploit in their tests. "The debug interface is subject to change at any time and should thus not to be used for production," Koch wrote. The fix routes the same data through a hex dump helper instead of a format-string logger.

The second issue is an integer underflow and buffer overflow in libgcrypt's RSA-PSS verification. It was found with help from Anthropic's Claude, manually reviewed, and fixed in libgcrypt 1.12.3 without a CVE. Groves said a logic error corrupts size calculations so an out-of-bounds write lands on allocator metadata; weaponizing it would need on the order of a 53-bit preimage under a hash the attacker chooses, with SHA-1 the cheap option, plus multiple certificates again to handle ASLR. The gpg.fail team did not finish that exploit after the other report landed and the patch shipped. Clemens Lang of Red Hat's crypto team argued a CVE is still warranted so S/MIME and GnuPG users can track backports in widely deployed code.