*THIS* is the official word

[Alex Kremer <axe@cybercomm.net>]

This was posted by Brandon Eich in the Netscape Developers Board:

Subject:  Re: Request for Security Update 
Date:   Thu, 29 Feb 1996 19:52:53 -0800 
From: Brendan Eich <brendan@atm.mcom.com>
Organization: Netscape Communications 
 Newsgroups: netscape.devs-javascript
 References: 
         1 , 2


> Furthermore, given these pretty serious holes, are there any pointers to

Please see below for more on the most serious of the alleged holes, which
are all
false in 2.0.

I consider the directory listing and mail spamming/address-stealing holes
serious;
the history tracker less so.

We're fixing directory listing and mail spamming, plus adding a Preference to
disable JavaScript, in a special 2.01 release that's about to supercede 2.0.
Also
in the Gold release, and (of course) in the "next release" (3.0b1, I believe).

> 1) a description of the security model used by JavaScript?  *Java* has at
> least some sense of formalism, it sounds like JavaScript's security policy
> is to piecemeal prevent specific holes as they are discovered and release new
> versions of Navigator.

First, some bones of contention:

"Sense of formalism" doesn't mean much: code is code and that's where
exploitable
bugs arise.  There have been more than a few serious Java security bugs
since the
alpha releases.  Just now, we're shipping a new .zip file to fix the "DNS
attack"
on Java's address-comparison security check, along with 2.01.

I put more faith in code reviews, and incentives for crackers to publicize their
exploits, but even between Sun's bringing in outside reviewers, and
Netscape's bugs
bounties, it took some fresh thinking by students at Princeton to find the
latest
Java flaw, the "DNS attack".  So much for sense of formalism.

Second, some facts about JavaScript:

JS uses an analogous "source control" model to Java's.  That is, scripts and the
documents they can examine (to see links[].href properties, as in the directory
stealing case) must come from the same server.  This policy was broken in
2.0 for
directory listings, due to a bug that was masked by other, working security
checks
for the original test case at http://www.c2.org/~aelana/javascript.html (the
latest
version of that page has been revised to unmask the remaining source control
hole
that shipped in 2.0).

Source controls are hard to get right, in Java as well as in JavaScript.
JavaScript has a simpler "destination control" problem than Java, however:
the only
back channels, covert or overt, are through URLs and form post data written
through
HTTP.  Therefore, in the next major release, I intend to support destination
checks
that are few and easy to get right (a proof is just a convincing argument).

These destination checks will test a "taint" bit associated with secret or
private
data, which propagates conservatively across data and control flow in
JavaScript.

So, for example, the session history strings censored in 2.0 during the beta
cycle
can be re-exposed to scripts, so long as they are tainted and all data
derived from
them algebraically or by control dependences are also tainted.  A script can
thus
present views of session history without being able to steal it by encoding
it and
sending it to a CGI as a URL or as form post data.

Another example of tainted data: all document text, link hrefs, and form
elements
loaded from any file: URL.

Users may cut and paste page elements into forms and submit them, without
pasting
taint, but such users are presumed to be fully competent and responsible for
their
cutting and pasting.

Form data that reflects with taint in JavaScript can likewise still be submitted
the old fashioned way, by a user pressing the submit button.  But the JavaScript
form.submit() method will fail if it finds taint among the JavaScript
reflections
of current form element data.

The "taint" jargon is borrowed from Perl, which does something similar but
subtly
different to prevent Unix setuid perl scripts from passing data gained due
to their
extra privilege to unprivileged sub-commands.

Is this enough for a sense of formalism?  It's something I'd like to write
up in a
more complete way, once it has been implemented and tested.

> 2) a way to *disable* javascript in navigator?  Not having found a
> configuration option, we've patched the binary to not recognize the SCRIPT
> tag, the onLoad function, and the "livescript:" URL scheme, but we'd like
> some confirmation that these are the only ways which LiveScript can be
> activated.

You need to change occurences of "javascript" too.

You should reconsider the benefit of this in light of the facts below about file
content, as opposed to file name, stealing.

> The security holes that David posted about are NOT minor,

As I wrote, the mail address-stealing and directory listing theft bugs are
major.

The "invisible monitoring" of all sites visited after loading a JavaScript,
which
refers to John Robert LoVerso's "history tracker" page, I consider minor
because it
is far from invisible on all the systems I've tested it on.

The remaining claims that David quoted, from one Lincoln D. Stein, are:

- the session history of visited URLs can be stolen.
- the user's disk cache can be stolen.
- finally, and I quote Lincoln D. Stein here:
>   In addition, it should be possible to exploit the same holes to grab
>   the user's list of subscribed newsgroups and to obtain the contents of
>   local disk files.

These are all false in 2.0.  I defy Stein or anyone else to provide a URL of a
working counterexample.

> and they are holes
> in the language, not in the implementation.

Wrong.  The language has nothing to do with what security policy, source
controls,
destination controls, data tainting, or a combination of all three, are used
by its
implementation to keep secret and private data from being stolen.  The language
does not define data access at all.

Neither does the language, as opposed to its implementations, have anything
to do
with security bugs in one or more implementations, for instance the bug in 2.0's
source control on the document.links property that left directory-listing
windows
exploitable.

> Netscape will be lucky if CERT
> doesn't issue a warning about this, in my opinion.

CERT had better not make the flagrant misstatements of fact, and misleading "it
should be possible" assertions, that Lincoln D. Stein makes.

Stand by for 2.01.

/be

(The above are my opinions, not Netscape company positions; so please argue
*with*
me, not *against* Netscape, based on facts and examples, not third-hand
assertions
and faulty speculations.)

Alex Kremer
axe@cybercomm.net
"Well, tough noogies. User Interface isn't always my strong point."

--------------------------------------------------------------------
This message came from the mailing list javascript. For help using the
mailing list software, please send a message to 'majordomo@obscure.org'
with the message body 'help'. To unsubscribe, send a message to
'majordomo@obscure.org' with the message body 'unsubscribe javascript'.