Security Flaw Discovered in GPG

WeLikeRoy writes "A serious problem in the use of GPG to verify digital signatures has been discovered, which also affects the use of gpg in email. It is possible for an attacker to take any signed message and inject extra arbitrary data without affecting the signed status of the message. Depending on how gpg is invoked, it may be possible to output just faked data as several variants of this attack have been discovered. All versions of gnupg prior to 1.4.2.2 are affected, and it is thus recommended to update GnuPG as soon as possible to version 1.4.2.2."

Comments

Re:Bug Intentionally Placed?

[aprilsound]

So instead of taking hours to obtain a GPG key, the NSA could spend seconds and impersonate an otherwise [strike]paranoid[/strike] privacy-oriented person in typically confidential memos.

I realize this is a joke, but just so everyone knows, a little bit of scrutiny would expose a faked message.

If you RTF Mailing List, you will see that the "attack" only allows someone to append or prepend data to the signed message, and then the augmented message is only displayed the way it is because of an application bug in GPG.

No fundamental algorithm is broken, no one has discovered a way to cause collisions. In fact, if you tried to independently verify the signature of the message against the augmented message, it would fail.

What happens is that GPG skips text that is not part of the signed message, such as email headers and the like, then verifies what is signed. Unfortunately, once it's verified, it will output the whole message, leading the user to believe that the whole message was signed.

Again if you checked the signature against the whole message it wouldn't verify, GPG is just being a bit too helpful.

Double Bag That Burger

[Doc Ruby]

Another good recommendation is to diversify your crypto. Sign/encrypt your data with multiple different crypto algorithms in the same message. It's like network redundancy: the odds of both methods failing at once are equal to the product of the low, but significant, probability of either failing. A single failure doesn't ever compromise your data, and buys time to get a new second method that works.

Of course, sent messages can't be recovered for reprotection with the new second method. And eventually the other original method will be compromised, so the attacker can use the appropriate methods for each. But at least you've improved your security. Probably more than the next guy. Next lesson: when the bear is chasing y'all, you don't have to be the fastest; just not the slowest.

GPG is:

[Black Copter Control]

what is GPG?

GPG stands for Gnu Privacy Guard. It's the Free(tm) replacement for PGP (Pretty Good Privacy) which was originally developed by RSA. Between them, they are one of the standards for encryption and verification of sensitive data (including email).

As opposed to X509/SSL which seems to be designed for centralized trusted certificate issuers, GPG/PGP depend on a (decentralized) web of trust -- You decide which signatures you wish to trust, and then those signatures can be used to signify who they trust... If you have enough trust in the signature web for a public key you have for someone, then it is presumed that the key is trustable.

GPG seems to be supported by people who include some serious heavyweights in the encryption community.

IANASE (I am not a security expert), so any corrections to this explanation would be much appreciated)

Re:GPG is:

[Martin Blank]

It's the Free(tm) replacement for PGP (Pretty Good Privacy) which was originally developed by RSA.

No, PGP wasn't developed by RSA; RSA had nothing at all to do with PGP's development. Use of the RSA asymmetric encryption algorithms has been in use since early versions, but PGP itself was developed by Phil Zimmerman, who got into a patent battle with RSA over his use of the algorithm without their permission (although patent co-holder MIT didn't have a problem with it, complicating the situation). A deal was eventually worked out, and the RSA algorithms have been in ever since.

Short explanation if you're too lazy to RTFA

[sidney]

The bug allows someone to take a signed GPG message, stick in their own unsigned message in a certain way, and GPG will show you the combined message or even just the new message, but tell you that it is signed by the person who signed the original message.

If you read the message using the new GPG 1.4.2.2 it will correctly not accept the hacked message. So if you have any question about signed mail you received, you can check it again after upgrading GPG.

The bug only affects embedded signatures, such as in email messages using inline signatures or signed encrypted email. I think that excludes PGP/MIME signed unencrypted email, which is a common format for signed mail and would be a form of detached signature.

The bug does not affect "detached signatures", which are the kind that are used to verify software downloads, which means it could not have been used to hack yum, apt-get, etc.

All in all, not a big security flaw unless someone takes a signed email that you sent them, forges a GPG signed request to your domain registrar to transfer your million dollar domain name to them, and your registrar hasn't yet updated to GPG 1.4.2.2. Whoops -- if you upgrade GPG right now, it wouldn't help in that scenario.

Re:Well...

[lspd]

I agree. But again, the way I read the alert, isn't this a "Man In the Middle" attack?

It's a replay attack. I take a very terse/vague signed message that you've written and append important evil data to the front or back and resend it. The signature checks out and the meat of the message (the stuff I've added on to the front or end) appears to come from you.

This sort of problem has come up before in other contexts. When you sign an email, for example, it's doesn't include the headers or date. If your signed message is general enough, I can copy it and send it to someone else (GPG signatures verify the sender, not the recipient.) One of the situations where this has come up is in the Debian voting process. If a DD mistakenly sends their ballot to the wrong person, then changes their vote, anyone who has a copy of the old ballot can send it again and change the vote back. Debian safeguards against this by allowing each DD to see how their vote was cast after the vote is complete.