[Cryptography] Crippling Javascript for safer browsing

[Arnold Reinhold]

On Wed, 4 Jun 2014 21:05 John Ioannidis wrote:
> 
> On Wed, Jun 4, 2014 at 7:36 AM, Jerry Leichter <leichter at lrw.com> wrote:
> 
>> As software engineers, we're always drawn to make our systems as general
>> and powerful as possible; but it's long been clear that power and security
>> are antithetical.  Javascript in browsers is a great example.  A browser is
>> fundamentally a display, and yet we've been drawn to include within it the
>> a Turing-complete programming language - which inevitably opens holes for
>> abuse, which then get patched or limited through some kind of wrapping
>> sandbox.
>> 
>> Meanwhile, the only full defense is browser extensions that simply block
>> Javascript completely - something that's impractical for most major
>> websites today.
>> 
>> The fundamental problem here is the accepted belief that a browser's
>> quality is related to the faithfulness of its implementation of the
>> Javascript specs - even when those specs lead to browsers that facilitate
>> attacks against their users.
>> 
>> Let me give a couple of examples of the kind of thing I'm talking about:
>> 
>> 1.  Javascript lets you create new windows - and because some companies
>> and programmers have a goal of allowing browser apps to look just like
>> native apps, it lets you create any kind of window at all.  As a result,
>> it's impossible for a browser to define a "secure password prompt" window
>> (though some - Safari, for example - have tried):  Anything the browser can
>> do, a Javascript hack can do.  Other attacks - e.g., clickjacking - are
>> based on the same basic power.
>> 
>> But why grant that power?  A Javascript implementation that always created
>> windows with a specific chrome on them, forced them to be visible, and
>> enforced a minimum size, might inconvenience some developers, but would
>> render a whole class of attacks impossible.  You might actually be able to
>> trust that a password prompt really *was* a password prompt.
>> 
>> 2.  Javascript implements a ton of environmental queries, from screen
>> resolution and size to fonts on the machine to cache information.  This
>> allows for easy fingerprinting of browsers.  A Javascript implementation
>> that simply lied about this stuff - rounding screen information to one of a
>> few standardized values, sending back a fixed list of standard fonts in a
>> standard order, and so on - could stop such attacks.
>> 
>> 3.  If a Javascript implementation ignored actions that triggered on
>> attempts to close a window, all kinds of extortionate programs would have a
>> much harder time harassing and terrifying ordinary users.
>> 
>> Of course, what I've said about Javascript applies equally well to other
>> browser facilities.  If there are things in HTML5 that make attacks easier
>> while not adding anything significant - don't implement them, or implement
>> them in a way that mitigates the risks, even if doing so violates the
>> standards.
>> 
>> It's a fundamental (and paradoxical-appearing) result in game theory that
>> sometimes deliberately limiting your own choices improves your position.
>> We've been discussing keeping the level of language in protocols low in
>> the Chomsky hierarchy to limit vulnerabilities in parsers.  The same idea
>> applies elsewhere.  It'll be a tough lesson to learn, given decades of
>> design philosophy that looks for ever more power - even the tools that
>> disable Javascript are perceived not as limitations but as a way to give
>> the user more choices.  But it's a lesson we need to learn if we're to have
>> any hope of building more secure systems.
>> 
>>                                                       -- Jerry
>> 
>> 
> Jerry, you know very well why none of these are ever going to happen. Why
> are you even bothering to enumerate them?

I think we are being a little too defeatist here. This is mostly a question of good marketing, not technology. A set of "security extensions" to Javascript that users could opt for might well be adopted if it had wide support from the security community. There are only a few major browser vendors and most have some interest in getting things right. The extensions would need to be well-thought out beforehand, and there is still the cat-herding problem, but getting organized is long overdue. 

And while we are on marketing, might I point out "FalseCrypt" is not an optimal choice of name for a TrueCrypt fork?  All for the fork, but really... How about PhoenixCrypt?

Arnold Reinhold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140605/087fd063/attachment.html>