Sergey Nivens - Fotolia

News Stay informed about the latest enterprise technology news and product updates.

Risk & Repeat: Breaking down the Efail flaws

Listen to this podcast

In this week's Risk & Repeat podcast, SearchSecurity editors discuss the Efail vulnerabilities in PGP and S/Mime protocols, as well as the rocky disclosure process for the flaws.

The unveiling of the Efail flaws in encryption client software led to spirited debates about the rocky disclosure of the vulnerabilities and who, ultimately, was responsible for them.

The vulnerabilities, which were discovered by a team of academic researchers in Germany and Belgium, affect some client software that implements two popular protocols for email encryption in Pretty Good Privacy (PGP) and Secure Multipurpose Internet Mail Extensions (S/Mime). The Efail flaws could allow threat actors to obtain the plaintext of messages encrypted with the affected client software.

The researchers' technical paper pointed to faulty email clients rather than the protocols themselves, which sparked a debate about who was responsible for the Efail flaws. While some infosec experts argued the developers were on the hook, others such as Matthew Green, professor at Johns Hopkins University's Information Security Institute, criticized organizations like GnuPG for not taking a more active role in addressing the problem. Additionally, a broken embargo for the branded vulnerabilities led to questions and concerns about coordinated disclosure processes.

Was there an overreaction to Efail? Who takes the majority of the blame for these vulnerabilities? Did the Efail disclosure actually fail? SearchSecurity editors Rob Wright and Peter Loshin discuss these questions and more in this episode of the Risk & Repeat podcast.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Who should take most of the blame for the Efail vulnerabilities?
To highlight the root of the problem, consider a closed system end to end secure mail provider with an OpenPGP standard compliant backend.  Because they have complete control, they can easily see and coordinate every step of the mail sending and receiving process.  Every sender and every sender is using their system.  I doubt any such closed system had any problems with EFAIL.  "Proton Mail" is one such system, and they are safe.  On the other hand, that only helps those who use that particular closed system - e.g. it does not allow secure OpenPGP communication between a Proton Mail user and and someone outside that system.  The Proton Mail website indicates they use a different method - a dropbox with a one time password, to pass messages from Proton users to outside the system.

Now consider the the case of non-closed OpenPGP mail systems.  The target is different - communication between any two parties regardless of the flavor/version of the OpenPGP based mail system. The reward is higher (wider communication) but the difficulty/costs is higher (ensuring compatibility between all those different flavors/versions). 

It so happens that the OpenPGP standard has required since at least 2003 every message to use an MDC (modification detection code), but there are multiple flavors of that code.  The OpenPGP standard is quite flexible about algorithm flavors - that is necessary for a standard that has to meet many different needs. 

Because of this difference in MDC format many systems silently dropped support for checking the code.    That was the failure exploited by EFAIL.  That failure was also a design choice made to maximize accessibility and development speed. That same choice was repeated many times over in many different flavors of mail clients - so in that sense it was predictable behavior in an distributed ecosystem without a central overseer.

Closed mail systems don't exactly compete with non-closed mail systems because their users have different needs. More likely, drop box and other non-mail forms of delivery are the fallback.

One idea for the future of open protocol standards and open software would be open accreditation to accompany the standards / software.  Mailers would be obliged to pass various practical tests to get the accreditation.  E.g., after a fresh default install, does it follow the complete standard protocol; does it warn every time if a required safety check (like MDC) is not met.  The accreditation board should publish compliance records so that users choose safe mailers.  That's not an extreme goal if it's considered as an essential component of open standards and software.

Something which is NOT a solution is obscure hard fails.  An example would be designing the GnuPG module to hold all encrypted data in module memory before release and blow up if there was a problem with the MDC.  Bad software design is not a substitute for good organization design.