[arch-security] [Arch Linux Security Advisory ASA-201412-1] gnupg: denial of service
Arch Linux Security Advisory ASA-201412-1 ========================================= Severity: Medium Date : 2014-12-01 CVE-ID : CVE-2014-9087 Package : gnupg Type : denial of service Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE-2014 Summary ======= The package gnupg before version 2.1.0-6 is vulnerable to the same denial of service issue than the one in libska (ASA-201411-31), as they share the same code. Resolution ========== Upgrade to 2.1.0-6. # pacman -Syu "gnupg>=2.1.0-6" The problem has been fixed upstream but no new version has been released yet for the 2.1.x branch. Workaround ========== None. Description =========== By using special crafted S/MIME messages or ECC based OpenPGP data, it is possible to create a buffer overflow. The bug is not easy to exploit because there only 80 possible values which can be used to overwrite memory. However, a denial of service is possible and someone may come up with other clever attacks. Thus this should be fix. Background: Hanno Böck found an invalid memory access in the 2.1 branch of GnuPG by conveying a malformed OID as part of an ECC key. It turned out that this bug has also been in libksba ever since and affects at least gpgsm and dirmngr. The code to convert an OID to its string representation has an obvious error of not considering an invalid encoding for arc-2. A first byte of 0x80 can be used to make a value of less then 80 and we then subtract 80 from it as required by the OID encoding rules. Due to the use of an unsigned integer this results in a pretty long value which won't fit anymore into the allocated buffer. Impact ====== A remote attacker can cause a denial of service by sending a specially crafted S/MIME message or ECC based OpenPGP data. References ========== http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9087 http://lists.gnupg.org/pipermail/gnupg-announce/2014q4/000359.html http://seclists.org/oss-sec/2014/q4/801 https://bugs.archlinux.org/task/42943
participants (1)
-
Remi Gacogne