8

Thomas Pornin brought up a good point about PGP key servers in an answer to a recent question, here:

Shouldn't GPG key fetching use a secure connection?

...you should not trust the key server...

Key servers are, after all, just another type of service that hosts what is essentially user-generated content. This got me to thinking then, about what security risks are inherent with receiving content from a public key server, which by its very nature cannot vouch for the content that it hosts?

The only real risk I can think of is if there happens to be a vulnerability in either the OpenPGP protocol or one of its implementations, which would allow an attacker to perform arbitrary code execution via a malformed key or signature. Have there been such vulnerabilities? Are there other risks involved, that I'm not thinking of? How can these risks (if any) be mitigated?

Community
  • 1
Iszi
  • 26,997
  • 18
  • 98
  • 163
  • But in the PGP example you are encrypting to that key. So in a usecase i want to send an encrypted email to joe@blogs.com . I connect to rogue PGP server and get alice@evil.com 's key. I encrypt my message to that key but as long as I still email joe@blogs.com what is the risk? Agree you should get keys over https and the PGP global server provides a signing key to verify the public keys you get from there but practically what is the risk? – Rakkhi Jun 02 '11 at 08:40
  • 2
    @Rakkhi, you simply shouldn't even encrypt with the public key of a PGP certificate you haven't verified as being that of the person you want to send the data to. It's not just about matching e-mail addresses. In addition, the whole point of encryption is to protect against e-mail interception (or other forms), so making the assumption that "as long I send it to the right e-mail address, it's OK" doesn't make sense. – Bruno Jun 02 '11 at 11:39
  • @Rakkhi - I'm not sure you're getting my theorized attack scenario. Say you're trying to encrypt an e-mail to bob@acme.com but you actually get a key that was maliciously crafted by evilbob@hackme.com. Essentially what you are doing here is loading a foreign, untrusted document (the key) onto your computer. So, I'm wondering if that document can be made to have the capability of hijacking the client or even breaking out of it to run actual code on the system. – Iszi Jun 02 '11 at 12:37
  • @bruno understood. I was checking whether that was the attack he was worried about i.e. unvalidated certificate. @iszi ok so the attack vector was more that the key could contain malware or be an entry point – Rakkhi Jun 02 '11 at 15:04

2 Answers2

10

I'm not sure if there's anything specific to OpenPGP, but the problem you describe doesn't seem specific to this context.

As far as I'm aware, the exploits that lead to arbitrary code execution (e.g. based on buffer overflows) could happen to the processing of any type of a priori untrusted data that could be processed. Whether it happens in the code that processed a malformed key or any other form of data probably doesn't matter that much in this context.

Whenever you run some code that processes some data that you don't already trust (and in a way that you trust), you want that code to be bug-free, at least free of bugs that would lead to arbitrary code execution or other security problems. Whether the data is used later by a security mechanism is a secondary concern in this case. (Of course you also want the implementation of the necessary signature verification to be correct. That's where it matters for security purposes.)

The same type of issue could happen with any X.509-based TLS stack, for example. You'd want the TLS stack not to allow malformed certificates let an attacker get control of your system (again, that's true of any system that process a bunch of bytes it doesn't know in advance). The correct validation and verification of the certificate that will let you trust the TLS connection established once the handshake has completed successfully is very important, but only a secondary matter, then.

I think the main difference compared to other types of data is in the difficulty of implementing this type of code correctly. The storage structures used in the context of PGP or X.509 tend to rely on ASN.1, which can be about as clear as mud in many cases. Writing bug-free code that deals with ASN.1 isn't easy (IMHO).

I think Thomas's quote ("...you should not trust the key server...") had more to do with the fact you can't trust the key server as an entity vouching for the key it serves. This is just a hosting service, as opposed to an editor/publisher/author.

nealmcb
  • 20,544
  • 6
  • 69
  • 116
Bruno
  • 10,765
  • 1
  • 39
  • 59
  • You've hit the nail right on the head with regards to @ThomasPornin's quote. That the key server is just a hosting service and cannot vouch for the keys that it serves is *exactly* why I'm asking about this type of vulnerability. – Iszi Jun 02 '11 at 13:59
  • actually there is very little ASN.1 in OpenPGP, whereas X.509 is full of it. OpenPGP messages are meant to be decoded with ad hoc code, while X.509 certificates almost require a generic ASN.1 decoder. – Thomas Pornin Jun 02 '11 at 22:48
7

Your concern is very valid.

In 2000, Ralf Senderek discovered a bug in NAI's commercial versions 5.5.x through 6.5.3 of PGP: Key-Experiments. It was especially embarasing because it involved implementation of the "Additional Decryption Key (ADK)" capability (with goals similar to key escrow), an aspect of the commercial PGP software that many already objected to in principle. It allowed an attacker to modify a user's key (certificate) to add their own key as an additional decryption key, and thus decrypt intercepted messages made with the vulnerable versions of PGP. NAI very quickly released fixed versions, and also updated keyservers to detect that problem and two related problems with designated revokers - see Zimmerman's reply. Note that GnuPG refuses to support ADK at all.

Here is another example, though not with keyservers or PGP. A buffer overflow attack which "may allow the execution of arbitrary code" was seen in 2010 for at least one product with X.509 certs. In that case it actually happened during a conversation with an untrustworthy endpoint: yaSSL Certificate Processing Buffer Overflow Vulnerability - CNET

How can you avoid these kinds of problems? In this specific case, it is of course best to get your keys directly and securely from the folks you want to correspond with. I list protocols that are more secure than the traditional (but non-standardized and insecure) HKP keyserver protocol at Shouldn't GPG key fetching use a secure connection?.

Beyond that, general software hygiene applies. Use well-studied software from folks known for secure practices, keep your software up-to-date, be careful about where you get any kind of data which you process on your computer, minimize your attack surface, compartmentalize your data processing, etc.

Community
  • 1
nealmcb
  • 20,544
  • 6
  • 69
  • 116