Subj : Re: Tainting in Rhino
To   : netscape.public.mozilla.jseng
From : news
Date : Thu Jul 29 2004 11:27 am

Thanks for your prompt replies. First, let me say that I am happy to see
Brendan still working on JS; I interned at the JavaScript group at Netscape
back in 1998, when Clay Lewis was its manager...

Let me give you a bit more background: I work at a research group at
Stanford doing language security. As part of our research, we came up with a
runtime tool that allows you, among other things, to
    1. provide sources and sinks
    2. automatically instrument the relevant Java code to maintain taint
throughout the program.

Then the JavaSource would be automatically instrumented to obtain something
like rhino_instr.jar. We have applied this technique to other types of Java
program to discover various propagation-related properties. I thought there
would be something in the context of Rhino embedding, especially because it
doesn't lend itself to static analysis, as the exact propagation behavious
is script-dependent.

-Ben

"Brendan Eich" <brendan@meer.net> wrote in message
news:41091C8A.2010900@meer.net...
> Igor Bukanov wrote:
> > Benjamin Livshits wrote:
> >
> >> I was wondering if anybody has thought about or tried to implement
> >> tainting a la Perl in Rhino.
> >>
> >> I think it should be useful for browser embeddings to prevent data
> >> from forms to propagate to eval() calls, for instance.
> >
> >
> > I do not think it is useful since in an browser environment script can
> > only do what browser provides. If browser just implements a basic DOM
> > then there is no way scripts can do harm except consuming all the memory
> > and opening zillions of windows.
> >
> > If on the other hand browser allows, for example, LiveConnect to script
> > Java objects (which is supported by default in Rhino), then the script
> > can do whatever Java code can do. For example, AFAIK ICEBrowser treat
> > all the scripts in the same way as it treats untrusted Java applets and
> > use the standard SecuriManager techniques to implement the proper
sandbox.
>
>
> Igor's right, the same-origin
> (http://www.mozilla.org/projects/security/components/same-origin.html)
> sandbox model for JS, and the applet sandbox model, are well known and
> sufficient (once correctly implemented!).
>
> But I'll go further.  I implemented data tainting in Netscape 3 for JS.
>   It did not work well.  Taint tends to accumulate conservatively, and
> poisons the well, so to speak.  It has to, or timing channels won't be
> blinded properly (someone actually developed a timing-channel attack on
> a page in the 3.0 era, believe it or not).
>
> Plus, tainting is inefficient in terms of interpreter or JITed code
> overhead.
>
> I don't see the point in tainting, but please provide some use-cases or
> thoughts if you have suggestions.
>
> /be

.