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

Debian unstable's got me covered

[Anonymous Coward]

Since I use GnuPG to sign my e-mails (not that I believe anyone actually verifies the signatures, nor do I send any e-mails for which it would really matter all that much -- it just seems like good practice), I ran to check my version of GnuPG as soon as I saw the /. blurb.

1.4.2-2

Hmm. The -2 means that this is the second packaging of the 1.4.2 release. So it's been out for a while. Checking the changelog, I see that 1.4.2-1 was released 24 Sep 2005. My system would have gotten the update within a couple of days of that release date, so I got the fix nearly six months *before* the vulnerability announcement.

Can't complain about that!

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.

Re:Debian unstable's got me covered. Um NO.

[Anonymous Coward]

The parent AC is worng.
1.4.2-2 is not equal to 1.4.2.2, and it is older than 1.4.2.2
the -2 is the 2nd Debian modification of 1.4.2

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.

Re:software or data flaw?

[Black Copter Control]

no flaw in encoding or decoding..
The problem is in display. It displays the unencoded preamble and postscript inline with the (properly) verified parts of the email. You then, essentially, have to guess which is which.

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:

[Zeinfeld]

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

Given the lawsuits that RSA filed to stop PGP this statement could hardly be more wrong. Phil Zimmerman developed PGP as freeware, then released a commercial version of his code and reclaimed the name. GPG is a name chosen to describe the free version.

This crack is not particularly new, the first version of PGP had the problem. The only part of the message that is secure is the part between the begin and end signature bars. PGP/MIME fixes this problem but MIME creates new ones.

PGP Inc sells a fine PGP client that also does a pretty good S/MIME. I have no problem with the PGP protocol or a carefully designed, properly integrated plug in.

What I do have a problem with is the idea that effective security can be delivered as an ad-hoc bolt on to be lashed into place with some perl scripts. If you want to do end-to-end security you have to come to terms with the fact that the real end point is the user.

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.

Re:GPG is:

[Rikus]

GPG is a name chosen to describe the free version.
This sentence is neither informative nor funny.

No, GnuPG is not the same as PGP. GnuPG was in fact developed to replace PGP, both because PGP is covered by a non-commercial use only license, and (probably) because it by default incorporates the patented IDEA algorithm. Yes, PGP Freeware and GPG are both free and interoperable, but they are not the same thing.

Re:GPG is:

[Chapter80]

Correct about Phil Zimmerman, and his battles with RSA. Phil also got in trouble with the NSA (National Security Agency branch of the US Government) for the release of PGP. It was a bold move by Phil for the freedom of the software around the world, and he's a freedom hero in my book.

Back then (early '90s), simple encryption SOFTWARE was considered a munition, similar to if he snuck an atom bomb out of the country. The software was "released" onto the evil internet (perhaps not even by Phil), and as I recall, Phil was arrested or charged, or questioned.

My history is based on memory from reading Boardwatch magazine (a GREAT internet publication in the hey-day). So I may not recall 100% correctly.

Re:GPG is:

[Zeinfeld]

No, GnuPG is not the same as PGP. GnuPG was in fact developed to replace PGP, both because PGP is covered by a non-commercial use only license, and (probably) because it by default incorporates the patented IDEA algorithm. Yes, PGP Freeware and GPG are both free and interoperable, but they are not the same thing.

The full story is a bit more complex. The original PGP used a lot of patented stuff only Phil Z. did not bother to get a license for any of it. This led Jim Bizdos to complain about the patent infringement which led to Louis Freeh's FBI persecuting Phil. That is why folk found the idea that Bizdos was behing PGP, he almost had Phil Z. sent to jail for distributing it (although in fairness to Jim he did not anticipate Freeh persuing the case in the way he did and his objective was to stop Phil infringing his patent not send him to jail.)

The PGP code was rewritten quite a few times for a number of reasons. MIT brought out a legal version that used the non-commercial use license from MIT. The MIT portions were open source but the RSAREF part was encumbered.

GPG started as an attempt to develop an entirely unencumbered version of PGP after the Diffie Hellman patent expired in 97. The IDEA algorithm would have been dropped even if it had not been patented as it had been compromised by then. A second implementation was in any case required to get OpenPGP accepted as an IETF standard.

Around the same time Phil Z. was starting PGP inc and wanted to use PGP as the company name. Otherwise the FSF version would have probably been called something like GnuPGP.

actually not

[kelnos]

Actually, 1.4.2-2 is the second *Debian* release of 1.4.2, probably to fix packaging bugs or minor bugs in the software that weren't yet available in an upstream release. 1.4.2-2 != 1.4.2.2. Debian users still need to upgrade when a new package is available.

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.

Triple bag it

[Anonymous Coward]

"For instance, the use of double encryption does not provide the expected increase in security [MH81] when compared with the increased implementation requirements, and it cannot be recommended as a good alternative. Instead, triple-encryption is the point at which multiple encryption gives substantial improvements in security."

From http://www.x5.net/faqs/crypto/q85.html

Well...

[jd]

It is true that 95% of users don't use GPG, but I'd regard that as a flaw in and of itself. Mind you, most e-mail programs (including, IIRC, thunderbird) don't support GPG, although some do support a limited range of digital certificates.

Does it make the e-mails less safe? No. First, the flaw is for adding material, not reading it. Second, it's for signing, not encryption per-se. It DOES mean that you cannot trust e-mail for commercially sensitive transactions, but nobody should be trusting e-mail for that anyway.

Does it affect routers or the infrastructure of the Internet? Only insofar as domain registrars never validate change requests properly. A carefully-crafted attack could use this to append a change-of-IP request to some ISP's routine request to a registrar, which means an attacker could create a phony DNS server for the express purpose of polluting the DNS namespace. If the registrar uses GPG's validation as proof of a legit request (and some are quite happy with a fax with no proof of origin at all) then it could have an impact.

Is this a likely scenario? No. The problem with lack of validation has been around for decades and has been used by cybersquatters and porn merchants, but never (as far as I know) for Black Hat activities. The lack of any significant effort has never been due to security. My best guess is that it's due to skript kiddies being clueless. Which is just as well. If demonstrable and simple exploits aren't being used to cause catastrophic levels of mayhem, then I think we're pretty safe against this somewhat more sophisticated vulnerability requiring (as you coorectly point out) a MitM attack.

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.

Re:Well...

[DrXym]

The Enigmail extension for T-Bird works as a front-end to GPG.

And very well it works too. I've been using it to communicate with someone who insists on encrypting their mail and it works fine. The biggest problem with it is that it somewhat assumes a familiarity with GPG in the first place to import keys and so on.

It works much better than SMIME which apps like Mozilla, Outlook Express have supported natively for years. SMIME is close to being unusable. It's not those app's faults (although the companys are partly to blame for adopting the standard). It's just that getting a cert for email is like extracting teeth and the encryption is horribly slow and bloated.

Re:Enigmail is fine...

[prasinos]

FWIW, mutt handles signed messages just fine: it shows which parts were signed and which were not. So this bug is not such a big deal.

Your version number may not change

[ajs]

Please note that when you update, your version number may not change. Depending on what OS you use and who you get your updates from, you might get an old version with back-ported fixes. If your version number is not the one mentioned here, you need to check with your OS vendor. Most will have a Web site listing security updates and what vulnerabilities they address.

Some facts about the flaw

[Gemini]

In an effort to inject some facts here:

1. This does not apply to signed software tarballs (like the Linux kernel)
   
   
2. This does not apply to PGP/MIME signed email messages (a la mutt, Enigmail, etc)
   
   
3. This does not apply to clearsigned email messages (a la everything else)
   

This applies to a very specific case where a message is constructed by hand with multiple data packets and a single signature packet, so:

1. It might apply to PGP/MIME signed+encrypted email messages.
   
   
2. It might apply to sign+encrypted messages in general.
   
   
3. It might apply to unencrypted-but-binary-signed messages (essentially signed+encrypted without the encryption - generally not used much).
   

I say "might" as in all of these cases it depends on how GnuPG is called.