From the official GnuPG advisory: "Signature verification of non-detached signatures may give a positive result but when extracting the signed data, this data may be prepended or appended with extra data not covered by the signature. Thus it is possible for an attacker to take any signed message and inject extra arbitrary data." All versions < 1.4.2.2 are affected. This means all versions maintained by FL. Debian has got a fix for 1.0.6 (*)--it might work for 7.3, and 1.4.1 (+). I am not aware of any fixes for 1.2.x (as found in RH9 and FC1-3 afaict) right now. (*)http://security.debian.org/pool/updates/main/g/gnupg/gnupg_1.0.6-4woody5.diff.gz (+)http://security.debian.org/pool/updates/main/g/gnupg/gnupg_1.4.1-1.sarge3.diff.gz BTW: When we're working on it, we should look at http://lists.gnupg.org/pipermail/gnupg-announce/2006q1/000211.html http://lists.gnupg.org/pipermail/gnupg-announce/2005q1/000191.html as well.
I'm inclined to follow what redhat did for RHEL and patch CVE-2006-0049 and CVE-2006-0455 (the first gnupg announce link you posted). The 2nd gnupg announce link you posted seems to be more theoretical than anything - I think we can safely put off that patch unless there are any objections? Also, can somebody please add CVE-2006-0455 to the Summary?
1. changed summary to cover both CVE's 2. I agree "2005q1/000191.html" is mostly theoretical, OTOH it can affect some real uses of GPG and the patch is trivial (three one-liners) 3. RH has published its fixes for both issues: https://rhn.redhat.com/errata/RHSA-2006-0266.html with patches for 1.0.7, 1.2.1 and 1.2.6
Thanks. I'm working on some updated packages. I built updates for RH7.3 and RH9 using the patches from RHEL, but it looks like the CVE-2006-0049 patch will need a bit of massaging to work with the fc 1/2/3 packages. I'll post them once they're complete. I'll take a look at the patch for the 000191.html link.
Whoops, I shoulda spoken up sooner. I didn't include "2005q1/000191.html" because I thought we were trying to stick to RHEL and other vendor tested patches as much as possible... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have created the following RPMs for CVE-2006-0049 and CVE-2006-0455: rh73: ae330358d3de07293d38c03d3be78cfbab3c8e11 http://lance.maner.org/gnupg-1.0.7-13.1.legacy.src.rpm rh9: 11c42d52e77427ead851555229d5f6374fa7babb http://lance.maner.org/gnupg-1.2.1-9.1.legacy.src.rpm fc1: 3ed633f01d7bab853001101e95e9d4d59ca1dc94 http://lance.maner.org/gnupg-1.2.3-2.1.legacy.src.rpm fc2: 033ddc97fa6b7c81859546ddd69f003eff42bde3 http://lance.maner.org/gnupg-1.2.4-2.2.legacy.src.rpm fc3: e07b00615272cbf14dac9dce10837fc7f88ca3a6 http://lance.maner.org/gnupg-1.2.7-1.1.legacy.src.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) iD8DBQFEGNI6pxMPKJzn2lIRAksMAJ9VaxafL9oFqqPXSAOvIMP9CjCjTACfbOuP Dky2kBnUPK2qCTbs5CmDmYE= =ozee -----END PGP SIGNATURE-----
Is there consensus yet whether Don's approach is "good enough" ? If yes, I'll go ahead and do PUBLISH QA. Speak up within a day...
Regarding "2005q1/000191.html", From <http://www.pgp.com/library/ctocorner/openpgp.html>: "What does this discovery mean to OpenPGP users? "If you use an OpenPGP-based program such as PGP® solutions, Gnu Privacy Guard, or Hushmail to encrypt and decrypt emails or files, Mister's and Zuccherato's discovery does not affect you. ... "We know of no real-world application that is affected by this type of attack. It is an attack that requires the active participation of someone who holds the actual key required to decrypt a message. Thus, it is not something you are likely to see. "If, however, you are using an OpenPGP-based program that is part of an automated system that takes encrypted data, decrypts the data block, and gives feedback to the submitter about whether the data block was properly decrypted, then you may be affected. Again, we know of no real-world systems that are affected, but we can mentally construct applications that *might* be affected." Basing an opinion on the above, my thought is it is unlikely that a fix to the "2005q1/000191.html" issue will be useful to our users. But I am no cryptography expert. So I vote "good enough."
I second that "good enough" vote. Let's stick to just what RHEL patched.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA w/ rpm-build-compare.sh: - source integrity good - spec file changes minimal - patches either come directly from RHEL or are derivations of those +PUBLISH RHL73, RHL9, FC1, FC2, FC3 ae330358d3de07293d38c03d3be78cfbab3c8e11 gnupg-1.0.7-13.1.legacy.src.rpm 11c42d52e77427ead851555229d5f6374fa7babb gnupg-1.2.1-9.1.legacy.src.rpm 3ed633f01d7bab853001101e95e9d4d59ca1dc94 gnupg-1.2.3-2.1.legacy.src.rpm 033ddc97fa6b7c81859546ddd69f003eff42bde3 gnupg-1.2.4-2.2.legacy.src.rpm e07b00615272cbf14dac9dce10837fc7f88ca3a6 gnupg-1.2.7-1.1.legacy.src.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFEGoeXGHbTkzxSL7QRApl9AJ4kVlp8wvplSXuzS6eAUK/r7yLF/QCfYVhZ 1B3eTRrEjgu+OUzCI0xa6DU= =kOjd -----END PGP SIGNATURE-----
Packages were pushed to updates-testing
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 b551dcbc9739ca6af6ca175c61709d5a4209fee6 gnupg-1.2.1-9.2.legacy.i386.rpm installs OK. key generation, encryption, decryption, signing and verification all work OK. +VERIFY RH9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEK9smePtvKV31zw4RArJBAJ9C9qnvt9qXZaVQRWVdsqXN9ptT0ACggwjy WE4PNyDa4L6nusXOdyNOyGs= =4u2K -----END PGP SIGNATURE-----
I looked at RHL73 binary with rpm-build-compare.sh, and saw a couple of things which seemed troubling: +ld-linux.so.2 +libcrypto.so.2 +libcrypt.so.1 +libgdbm.so.2 +libpam.so.0 +libsasl.so.7 +libssl.so.2 ..lots of pulled in new dependencies? -perl(Getopt::Std) ..I wonder if something would break due to removal of this dependency? --rw-r--r-- root root 16212 /usr/share/info/gpg.info.gz +-rw-r--r-- root root 29 /usr/share/info/gpg.info.gz .. gpg info page seems to be missing/truncated?
I can't figure out how the original rh73 gnupg package was built without pulling in those dependencies. As soon as I add openldap-devel to get ldap support built in, those come with it. Any ideas? The perl dependency is normal. It's a side-effect of removing the perl script from gnupg. I don't think anything else in gnupg uses perl besides the script that was removed. Man page does look broken. I'll have to take a look at it.
It seems /usr/bin/gpgkeys_ldap had dependency to those but other binaries didn't, so it seems the deps weren't being pulled in properly in the past for whatever reason.
Updated packages for rh73 were pushed to updates testing.
"It's a side-effect of removing the perl script from gnupg." ==> I note that at least on RHL73 it was not removed (but was indeed removed on RHL9); was this intentional? In case it should remain, here's my VERIFY vote. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA for RHL73 (gnupg-1.0.7-13.3.legacy.i386.rpm). Signature OK, upgrades OK. Verification and signing works fine. +VERIFY RHL73 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFEL/07GHbTkzxSL7QRAidfAKDJsV3DyBVtHhIljjnIgXUYiPGJiACfYWLw bvW4ZsqL9e0wi8unKvK50J8= =Do76 -----END PGP SIGNATURE-----
humm...something is odd...I thought the missing perl file was part of the security fix, but it doesn't appear so. I'll have to look into this.
Any update on checking the perl file..?
It appears the last RH update for 7.3 (gnupg-1.0.7-7) was built with a newer RPM than present in 7.3. In particular, RPM the update in question was built with had the following two features: 1. its find-requires did not use ldd to collect dependencies on dynamic libraries (only objdump reporting direct dependencies; ldd reports full transitive closure) 2. it had a working perl-req.pl (its non-executable in 7.3) AFAICT, it looked more like RPM in 9 than RPM in 7.3.
So, is the RHL73 rpm we have now something we can release, or are changes required?
It should be good to go.
Great.
Packages were released to updates.
Although this bug is already closed, I'm putting in an unofficial vote VERIFY+ FC1, as the released packages have been working for me for over a week with nary a problem. Good work, Donald! :-) (And Marc and Pekka!) :)