At the ongoing conference 39C3 (Chaos Communication Congress) in Germany, details were revealed about 12 previously unknown and unpatched (0-day) vulnerabilities in the GnuPG (GNU Privacy Guard) toolkit, which provides OpenPGP and S/MIME compliant utilities for data encryption, handling electronic signatures, key management, and access to public key repositories. The most dangerous vulnerabilities allow bypassing the digital signature check and enable code execution when processing encrypted data in ASCII representation (ASCII Armor). Working exploit prototypes and patches are promised to be published later. CVE identifiers have not yet been assigned.
The vulnerabilities are caused by errors in the data handling and format parsing code and are not related to flaws in cryptographic algorithms. For example, an error in the parser leads to a failure in accurately determining signed data and creates conditions under which the checked data may not match the signed data, allowing an attacker to tamper with the plaintext without access to the private key.
Identified issues:
- An error in the parser code for encrypted data distributed in ASCII-Armor format (text files with a block labeled 'BEGIN/END PGP ARMORED FILE') leads to out-of-bounds writes in memory. This issue may allow code execution when processing specially crafted data in gpg. The vulnerability manifests in the armor_filter() function and is caused by an incorrect increment of the counter 'n' in the 'for' loop — despite the 'n++' being specified in the loop itself, the counter is incremented again in the loop body when writing data to the buffer 'buf[n++]'. This results in an extra byte being written beyond the buffer's limit, and the variable representing size 'ret_len' is set to a value exceeding the actual size.
- The ability to create or overwrite any file, within the limits of current access permissions, due to improper handling of the 'filename' field in the data packet. This vulnerability can be exploited to execute code on the system when the recipient runs the commands 'gpg --decrypt poc.enc' and 'gpg poc.enc' to view the file poc.enc sent by the attacker. Code execution can be achieved, for example, by creating files such as ~/ .bash_completion or ~/ .ssh/ authorized_keys.
- The ability to substitute the plaintext displayed to the user when specifying the "—decrypt" option and verifying using separately provided digital signatures (Detached Signature, created with the "—detach-sig" option and supplied in a separate sig file). The essence of the problem is that when the message and sig file are sent separately, an attacker controlling the intermediate traffic (MITM) can make changes to the sig file, after which the verification remains successful, but when viewing the message from the sig file using the "—decrypt" option, different content will be output. echo Plaintext > plaintext gpg —detach-sig plaintext # modification plaintext.sig by the attacker by adding extra text gpg —verify plaintext.sig plaintext # verified gpg —decrypt plaintext.sig # verified, but different text is output
- The ability to append arbitrary data to a signed message while maintaining successful signature verification. The problem arises due to data truncation at the 20000-character boundary when computing the hash.
- Incorrect verification of authenticated encryption codes (MDC — Modification Detection Codes), allowing manipulation of encrypted packets such that when decrypted, the resulting content is processed as a different type of packet (for example, perceived as intended for the publishing of a public key).
- The ability to substitute additional data in CS signatures (Cleartext Signature) created using the flag "—not-dash-escaped" or converted from separately supplied signatures (Detached Signature). This vulnerability can be used to create a false impression for the user about what data was actually signed. For example, a user may download a valid key from trusted sources for verifying a digital signature, but an attacker during a MITM attack may substitute the ISO image being downloaded by the user and add an additional hash to the signature of the image, such that the verification of the substituted image passes successfully with the presence of a correct verifying key in the system.
- Substitution of additional data in the ASCII representation of a CS signature (Cleartext Signature) by inserting a null character. The vulnerability, for example, allows arbitrary text to be inserted into the Hash header.
- Incorrect interpretation of the OpenPGP format, which allows an ASCII-encoded message 'One-Pass Signed Message' to be processed as a 'Cleartext Signature' under certain header changes. The vulnerability enables the original signed data to be replaced with malicious content while maintaining the appearance of successful verification.
- The lack of explicit separation in the output of information regarding the success of the digital signature verification and the message content, which allows the creation of forged unsigned messages that appear genuine when executing 'gpg --decrypt'.
- The ability to create OpenPGP messages that are processed differently in gpg than in other OpenPGP implementations. The issue is caused by the handling specifics of very long lines in the ASCII representation of OpenPGP data.
- Creating conditions during the digital signature verification process that roll back the hash verification algorithm to the insecure SHA1.
- The possibility of substituting one's secondary keys (subkeys) without their authorization using the private component of the master key. The attack is carried out by adding a fake key storage via the '--keyring' option.
Additionally, two vulnerabilities have been identified in minisign, a simplified tool for creating and verifying digital signatures. Both vulnerabilities (1, 2) allow the use of terminal control sequences ('\e[1E') or special characters ('\r') in the comment field to modify the program's output, for instance, to replace verification result information.
Source: opennet.ru
