Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

6/5/2018
02:30 PM
Adam Shostack
Adam Shostack
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

'EFAIL' Is Why We Can’t Have Golden Keys

A deep dive into the issues surrounding an HTML email attack.

There's a newly announced set of issues labeled the "EFAIL encryption flaw" that reduces the security of PGP and S/MIME emails. Some of the issues are about HTML email parsing, others are about the use of CBC encryption. All show how hard it is to engineer secure systems, especially when those systems are composed of many components that had disparate design goals.

According to the announcement from the EFAIL website:

In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs.

Let's take a closer look at the HTML issues, because they're easier to understand, and because they're system issues, not crypto issues. The way the HTML attack works is that there are three parts to an email. The first is an HTML image tag with an opening quote but no closing quote. The second is the encrypted message, and the third is a close for the image tag. The Web display engine incorporated into some email clients assembles all of this into an HTML page, and in doing so sends the decrypted email to a server under the control of an attacker.

This is all pretty good stuff. It's not an attack on PGP or S/MIME but, rather, on the system in which those are embedded. (The CBC mode crypto is an attack on S/MIME.) There are reasons to be skeptical of the design or usability of PGP, and this attack bypasses all of them. PGP is designed conservatively, because the folks writing the code knew it would be attacked. PGP takes care to check inputs for reasonableness in all sorts of ways. In contrast, HTML parsers are designed to work when programmed by drunken idiots reading documents translated into Slovenian then French and displayed using the blink tag. It takes the robustness principle ("Be conservative in what you send, and liberal in what you accept.") to extreme lengths. And so the IMG tag issue at the heart of EFAIL is the HTML parser saying, "OK, here's the end of that URL! I better ask for it now!"

This makes for a great deal of robustness. You might think the alternative would be "someone should just look at the darn Web page and make sure it doesn't end with an error." That sounds great, but in the great Netscape-Internet Explorer war, when browsers were being coded and released competitively, the ability to parse more pages was a major competitive advantage. Moreover, today, a page working in IE on Windows is no guarantee that it will work on Safari on an iPhone. Robust, liberal parsing is part of why the Web has taken over the world, including email display. (Advertising and tracking is another part, but that's for another essay.) You might also think that we should have stricter parsing modes for HTML so that we could say "don't let this happen." HTML parsing is already complex, and a new, more conservative mode would multiply the complexity of the code.

Let's bring this around to Ray Ozzie's risky proposal, "Clear," and golden key proposals more generally. Each involves some highly sensitive code, and we want that code to be robust. Whatever the design of the golden key system happens to be, it's going to be embedded in complex systems. It's going to be dependent on many complex things. (Ozzie's proposal glibly involves video processing inside the trusted computing base.)

So, will the system be robust (secure in its availability property), or resistant to attack (secure in its confidentiality property)? We might want both, but as EFAIL shows us, we don't know how to engineer for both. Consequently, we need to keep our security systems as simple as we possibly can, so they can possibly work.

Related Content:

Adam is a consultant, entrepreneur, technologist, author and game designer. He's a member of the BlackHat Review Board and helped create the CVE and many other things. He currently helps organizations improve their security via Shostack & Associates, and advises startups ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Why Cybersecurity's Silence Matters to Black Lives
Tiffany Ricks, CEO, HacWare,  7/8/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internet—and What Your Organization Can Do About It
The Threat from the Internet—and What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-6486
PUBLISHED: 2020-07-10
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2012. Notes: none.
CVE-2012-6487
PUBLISHED: 2020-07-10
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2012. Notes: none.
CVE-2012-6488
PUBLISHED: 2020-07-10
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2012. Notes: none.
CVE-2012-6489
PUBLISHED: 2020-07-10
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2012. Notes: none.
CVE-2012-6490
PUBLISHED: 2020-07-10
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2012. Notes: none.