Subj : Re: Tainting in Rhino
To   : Benjamin Livshits
From : Brendan Eich
Date : Thu Jul 29 2004 09:49 am

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

.