[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
*THIS* is the official word
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 <firstname.lastname@example.org>
Organization: Netscape Communications
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
false in 2.0.
I consider the directory listing and mail spamming/address-stealing holes
the history tracker less so.
We're fixing directory listing and mail spamming, plus adding a Preference to
in the Gold release, and (of course) in the "next release" (3.0b1, I believe).
> 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
bugs arise. There have been more than a few serious Java security bugs
alpha releases. Just now, we're shipping a new .zip file to fix the "DNS
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
bounties, it took some fresh thinking by students at Princeton to find the
Java flaw, the "DNS attack". So much for sense of formalism.
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
directory listings, due to a bug that was masked by other, working security
version of that page has been revised to unmask the remaining source control
that shipped in 2.0).
back channels, covert or overt, are through URLs and form post data written
HTTP. Therefore, in the next major release, I intend to support destination
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
data, which propagates conservatively across data and control flow in
So, for example, the session history strings censored in 2.0 during the beta
can be re-exposed to scripts, so long as they are tainted and all data
them algebraically or by control dependences are also tainted. A script can
present views of session history without being able to steal it by encoding
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
loaded from any file: URL.
Users may cut and paste page elements into forms and submit them, without
taint, but such users are presumed to be fully competent and responsible for
cutting and pasting.
of current form element data.
The "taint" jargon is borrowed from Perl, which does something similar but
different to prevent Unix setuid perl scripts from passing data gained due
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.
> 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
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
refers to John Robert LoVerso's "history tracker" page, I consider minor
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
> and they are holes
> in the language, not in the implementation.
Wrong. The language has nothing to do with what security policy, source
destination controls, data tainting, or a combination of all three, are used
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
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
> 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.
(The above are my opinions, not Netscape company positions; so please argue
me, not *against* Netscape, based on facts and examples, not third-hand
and faulty speculations.)
"Well, tough noogies. User Interface isn't always my strong point."
mailing list software, please send a message to 'email@example.com'
with the message body 'help'. To unsubscribe, send a message to