gnupg can be tricked into verifying unsigned data by constructing an openpgp message containing multiple literal data packets. as it is ambiguous as to which packet contains the signed data, gpg can be tricked into producing a "good signature" message for modified or unsigned data.
Created attachment 81509 [details, diff] patch from Werner Koch of GnuPG project
no announcement yet, but upstream has committed changes to cvs. I suspect upstream will create a security release.
Removing herd as they can't access the bug through the alias, adding recent bumpers.
Created attachment 81641 [details] Demo mbox Attaching an example mbox file that should not verify, as the mesage has been modified (may depend on gpg options, this is not the only attack vector, but it's the simplest).
interim release 1.4.2.2 is tentatively scheduled for release tomorrow by upstream.
New version at : ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.2.2.bz2 Please bump. Vulnerability will be public in a few hours.
Bumped. Warning: I do not think this tarball has hit gnupg's mirrors yet.
Okay, public now, adding arches for stabilisation
*** Bug 125631 has been marked as a duplicate of this bug. ***
Tested on ppc: installs and builds fine. Handles the demo-mbox fine, shows: gpg: can't handle this ambiguous signature data (quick) Regression tests: * Signatures on -dev verify fine * Several files crypted and decrypted show no difference to original == Regression Tests passed == Please mark ppc stable.
stable on amd64.
sparc stable.
Alpha done. No regressions and does the right thing on the test case. However FEATURES="test" required FEATURES="-sandbox" to be used. It tried to write directly to /dev/stderr and sandbox didn't like that (no clue why). Cheers, Ferdy
ppc stable
x86 done
arm done
Stable on hppa
stable on ppc64
all security supported architectures stable, ready for glsa
GLSA 200603-08 Thx everyone. mips ppc-macos and s390 should still mark stable
we were not CC-ed, so, "sorry" about the delay. ppc-macos stable
