[Cryptography] Paranoia for a Monday Morning

Cole Sangster qggsme87t7 at snkmail.com
Mon Nov 3 03:18:17 EST 2014

On 2014-10-27 06:35, Jerry Leichter wrote:
> As I look at the world around me, however, I see few proven attacks
> against fielded cryptographic implementations - but an ever-flowing
> stream of attacks against another class of standardized software.
> I'm talking, of course, about browsers.  The complexity of browser
> standards - and of ancillary software like Flash - has proved way
> beyond our capability to program without error.

This is a sore subject for me. In all the discussions I've followed on
the matter, almost no one sees the big picture or addresses the critical
issues. I'll try to make the case as succinctly as I can.

> And that, of course, raises the question:  Accident, or enemy
> action?

While the NSA clearly exploits the situation, I see no reason to
attribute to malice what is amply explained by stupidity. The problem is
much bigger than the NSA.

In a nutshell, the current Web standards and practices are fundamentally
insecure and *fundamentally unsecurable*. And they are getting worse by
the day from a security point of view.

It is *impossible* for browser makers to whack all the moles. Their
efforts at shoring up the sandbox and improving code quality, though
beneficial, just amount to rearranging deck chairs on the Titanic.
Having effectively wrested control of key Web standards from the W3C,
the browser vendors are actually leading the lemming charge off the
cliff, all while touting their security prowess and spouting populist

What am I talking about, specifically? There are *so many* problems, but
if you're discussing getting browser implementations right, two issues
spring immediately to mind:

 1. HTML has become too linguistically complex to process with
confidence. The LANGSEC [1] people counsel that one should use as simple
an input language as possible (preferably context-free or simpler),
auto-generate a recognizer from the formal grammar, and fully recognize
the input before any further processing. The WHATWG [2] people say [3],
"Formal grammars be damned, we're going to specify an elaborate parsing
algorithm that accepts all sorts of broken versions of this byzantine,
cruft-laden language [which, by the way, is approaching
Turing-completeness when combined with shiny, new CSS3 [4]]." Yeah,
well, good luck with that.

 2. The "Modern Web" is entirely predicated on promiscuously running
Turing-complete JavaScript code in the browser from any old source with
nary a peep to the user about it. Holy pwnage, Batman! This is the
elephant in the room, and it boggles my mind that almost no one---even
among security folks---is screaming about it.

    I guess everyone has either given up, thinking the battle is lost,
or is buying into this notion that running arbitrary JS in the browser
is OK because it's in a sandbox. Here's why the sandbox is not sufficient:

     a. Until we have perfect, bug-free, formally-verified browser
implementations, the sandbox is always going to have holes. And adding
ever more APIs and features isn't going to reduce that attack surface.
Have a look at Firefox's vulnerability list [5] and notice how many of
them include a note like:

        > In general this flaw cannot be exploited through email in the
        > Thunderbird product because scripting is disabled, but is
        > potentially a risk in browser or browser-like contexts.

        Also notice how many vulns are memory-related and that they
aren't really dropping off over time as one might expect from a mature
implementation that's getting its kinks worked out. Maybe if the
browsers were re-written in memory-managed languages the number of
sandbox holes would be small enough to not be of much concern in
practice, but I'm not holding my breath.

     b. Even with a perfect sandbox, if one can do something *useful* in
the sandbox, one can do something *malicious*. We've seen this for a
long time with things such as XSS, pop-ups, and fake browser chrome, but
HTML5 is taking things even further. One of the driving forces behind
HTML5 is the dream of writing cross-platform mobile apps. But an
interesting mobile app will, of course, need access to the camera, the
microphone, etc., and HTML5 jumps in to provide. [6]

        What could possibly go wrong with turning browsers into
general-purpose computation platforms for use by random third parties?
Gee, I dunno. Maybe we could look at history: ActiveX, Java applets,
Flash. Well, sure, none of these turned out to be paragons of secure
computing, but I'm sure the WHATWG members are much smarter than their
predecessors and are going to get it right this time.

    Objections answered:

    "Even within the sandbox we're not going to let scripts do anything
really bad."
    Well, pardner, that's what we call "undecidable" 'round these here
parts. Having one program figure out what another program is going to do
before actually running it doesn't tend to work out well.

    "We'll be sure to ask the user for permission before letting scripts
access sensitive things like the camera."
    Now you're back to pestering users by asking them to make security
decisions that they're ill-equipped to make. They're usually just going
to click OK to make the nuisance go away. Furthermore, permission
systems like this always tend to be too coarse and too fine at the same
time. That is, they pester users too much while also letting too many
things slide in the name of simplicity.

    "Well, just don't visit sites you don't trust. Use some good judgment."
    This also boils down to asking users to make security decisions
they're not equipped to make. Most scripts are pulled from domains other
than the ones in the visible URL, so how could a normal user make an
informed decision? And if the page and scripts aren't pulled via HTTPS,
how can users be sure that they're getting code from where they think
they are? Even *with* HTTPS, there's room for doubt about the provenance
of code being run by the browser. And, of course, innocent sites
routinely have malicious code injected into them in various ways (XSS,
WordPress vulnerabilities, ad networks), so users can't even trust the

In short, the "Modern Web" pipe dream is one of cool, convenient, local
apps that Just Work after one click---no installation hassles! No
compatibility worries! No signature checks! But it depends upon browsers
to reliably evaluate, constrain, or neutralize foreign code, which just
isn't feasible. And in the cases in which they admit defeat and kick
decisions up to the user, they've lost the Just Works bit...and the user
can't reliably decide about the code, either.

So how did we arrive at this predicament? Intentional sabotage? No, it
just seems to be an emergent phenomenon that I've seen happen again and
again. It's similar to the tragedy of the commons [7] and could be
called the tragedy of security and technology.

Because security is an invisible feature that's expensive and difficult
to implement, new technologies are usually introduced with little or no
thought given to it. People aren't ready to make investments in security
until technologies are mainstream, firmly-entrenched, and finally
drawing prominent attacks. By that time, however, it's nearly or
absolutely impossible to properly secure the technologies, so
generations suffer from insecurity with brittle band-aid fixes until the
technologies are displaced by something else.

It's like the tragedy of the commons in the sense that individuals or
organizations, acting rationally and separately in their own short-term
interests, cause grief for everyone, including themselves, in the long run.

I see this at work just about everywhere---TCP/IP, email, DNS, Web,
medical equipment, electronic medical records, smartphones, smart
(electricity) meters, smart cars, smart TVs, and, more generally, the
Internet of Things. I cringe when I see those commercials with people
controlling their garage doors and faucets from their smartphones. God
help us all.

[1]: http://langsec.org/
[2]: https://whatwg.org/
[3]: https://html.spec.whatwg.org/multipage/syntax.html#parsing
[4]: https://github.com/elitheeli/stupid-machines
[5]: https://www.mozilla.org/security/known-vulnerabilities/firefox/
[6]: http://www.html5rocks.com/en/tutorials/getusermedia/intro/
[7]: https://en.wikipedia.org/wiki/Tragedy_of_the_commons

More information about the cryptography mailing list