Skip to main content
banner image
venafi logo

Certificate Poisoning Threatens GnuPG

Certificate Poisoning Threatens GnuPG

Certificate Poisoning Threatens GnuPG
July 8, 2019 | Guest Blogger: Anastasios Arampatzis

OpenPGP installations can break and fail to verify the authenticity of downloaded packages as the key server network has been flooded with thousands of spam signatures attesting ownership of a certificate.

The certificate spamming attack was discovered in the last week of June against Robert J. Hansen (known in the community as 'rjh') and Daniel Kahn Gillmor (known as 'dkg'), two high-profile contributors in the OpenPGP community involved in the GnuPG (GNU Privacy Guard) project. The attack impacts to various degrees the OpenPGP protocol implementations for signing packages and for encryption - like GnuPG, SequoiaPGP, and OpenPGP for JavaScript, causing them to slow their operations or even break them.

 

 

Why are TLS certificates such a hot commodity on the dark web? See the report.

 

How the attack works

Trust in OpenPGP certificates is maintained by distributing the public keys over a network of key servers that allow their discovery. To certify the ownership of the keys, users can attach a statement (certificate signature) to vouch that a key really belongs to the user listed in the database. The key servers' role is to store the information and synchronize it, without ever deleting any data, not even when certificates are revoked.

This system was created back in the 90s to prevent adversaries from replacing public certificates. As Hansen points out “In the early 1990s this design seemed sound. It is not sound in 2019. We've known it has problems for well over a decade.” The system is vulnerable to certificate spoofing and an attacker can add as many as 150,000 signatures for a certificate in the key server network, the maximum it can handle. OpenPGP does not have a limit to this and GnuPG cannot process this many signatures, Hansen explains.

Both Hansen and Gillmor had their certificates spammed so much that their public keys became unusable with GnuPG as it has to validate all the signatures. “Any time GnuPG has to deal with such a spammed certificate, GnuPG grinds to a halt. It doesn't stop, per se, but it gets wedged for so long it is for all intents and purposes completely unusable,” Hansen said.

According to Hansen, the effects are quite serious:

  • If you fetch a poisoned certificate from the key server network, you will break your GnuPG installation.
  • Poisoned certificates cannot be deleted from the key server network.
  • The number of deliberately poisoned certificates, currently at only a few, will only rise over time.
  • We do not know whether the attackers are intent on poisoning other certificates.
  • We do not even know the scope of the damage.

Hansen notes that any certificate can be poisoned this way and discovering the attack is likely to happen only when the OpenPGP installation breaks. The risks are significant, considering that GnuPG is a complete and free implementation of the OpenPGP standard and enjoys wide adoption among Linux-based operating systems. Its package is present in the repositories of the major distributions to ensure secure package management. Without being able to check if a package is authentic, upgrades are no longer possible, leaving systems vulnerable to security or performance problems that could be leveraged by an attacker.

How did we get to this?

Certificate flooding is not a new thing and attacks have been recorded before.

Matthew Green, a cryptographer and associate professor at Johns Hopkins University, said that the attack points out some of the weaknesses in the entire OpenPGP infrastructure. “PGP is old and kind of falling apart. There's not enough people maintaining it and it's full of legacy code. There are some people doing the lord's work in keeping it up, but it's not enough,” Green said.

This is admitted by Hansen as well. Hansen notes that key servers use an algorithm that can do fast reconciliations and rely on software called SKS, short for “Synchronizing Key Server”, which were developed by Yaron Minsky “in an unusual programming language called OCaml, and in a fairly idiosyncratic dialect of it at that.” According to Hansen, the problem is that “the software is Byzantine” and there is no one in the key server community that has sufficient "expertise in obscure programming languages and strange programming customs." As a result, the software remains “unmaintained” and a serious overhaul on the codebase is not possible at this time.

Daniel Gimor wrote in a post that “SKS is known to be vulnerable to this kind of Certificate Flooding, and is difficult to address due to the synchronization mechanism of the SKS pool. (SKS's synchronization assumes that all key servers have the same set of filters).” This vulnerability is not due to a bug that inhibits the key server network from functioning correctly. Bugs, generally speaking, are fairly easy to fix once you know where the problem is. The vulnerability is hard-coded into the actual key server design goals. “Changing design goals often requires an overhaul of such magnitude it may be better to just start over with a fresh sheet of paper,” says Hansen.

How to mitigate the attack

Both Hansen and Gilmor admit that a timely fix or mitigation is nowhere in sight, neither from the key server network community nor the OpenPGP Working Group. In fact, Hansen urges that “high-risk users should stop using the key server network immediately.”

A short-term mitigation is to disable automatic refreshing of the certificates. If this is needed, though, an abuse-resistant key server is the solution such as the keys.openpgp.org, “which is a new experimental key server that is not part of the key server network and has some features which make it resistant to this sort of attack,” as Hansen explains.

Gillmor said the attacks illustrate both the fragility and necessity of projects such as OpenPGP. “One of the points I've been driving at for years is that the goals of much of the work I care about (confidentiality; privacy; information security and data sovereignty; healthy communications systems) are not individual goods. They are interdependent, communally-constructed and communally-defended social properties,” he said.

That is exactly Venafi’s goal, to protect the machine identities on which companies heavily rely upon in a highly connected world. Contact the experts to learn more.

 

Learn more about machine identity protection. Explore now.

 

Related posts

 

 

 

Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

silhouette of a person waving goodbye at an airport

EV Certificates: It’s the End of the World as We Know It (and I Feel Fine)

executive man with forward looking glasses leaning up against a wall, self assured

Why Is NIST SP 1800-16 So Important? [Think Executive Buy-In]

two people starting at a robot, replacing their jobs

What is the ACME Protocol and How Has It Changed PKI?

About the author

Guest Blogger: Anastasios Arampatzis
Guest Blogger: Anastasios Arampatzis

Anastasios Arampatzis is a retired Hellenic Air Force officer with over 20 years of experience in evaluating cybersecurity and managing IT projects. He works as an informatics instructor at AKMI Educational Institute, while his interests include exploring the human side of cybersecurity.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat