Subj : Re: Again: Security Problem
To   : Keno Albrecht
From : Brendan Eich
Date : Thu Jul 08 2004 06:26 pm

Keno Albrecht wrote:
> Hello again :-),
> 
> My previous question with another flavor... This is really serious, I 
> hope to encourage some discussion. I tried everything on Windows XP, 
> Mozilla 1.7, and JDK 1.4.2/1.5b2.
> 
> Why can I write something like
> 
> var fos = new java.io.FileOutputStream(new java.io.File("somefile.txt"));
> 
> in a mozilla plugin (e.g. on clicking a xul-button)


Are you using chrome: URLs to load XUL for both these testcases, or for 
neither?  If you're using chrome: for the first, but not the second, 
that should cause different results (chrome: is trusted).  But surely 
that is too simple a theory....

Cc'ing LiveConnect folks.

/be


> and use it without 
> any problem/without any SecurityExceptions thrown, that is: e.g. write 
> to that file, but
> 
> var customObject = new Packages.my.own.CustomClass();
> 
> where my.own.CustomClass() is in the classpath (but not in [jre]/classes 
> or [jre]/lib/ext) and contains something like this:
> 
> public void CustomClass() {
>   try {
>     FileOutputStream fos = new FileOutputStream(new File("somefile.txt"));
>   } catch (Exception e) {
>     System.out.println("Annoying SecurityException thrown");
>   }
> }
> 
> ???
> 
> I mean: Obviously, these are two different approaches to handle Java 
> classes, resp., two different SecurityManagers used:
> 1) In the first example (JavaScript only/no custom class), there is no 
> restriction/no SecurityManager set --- I can do anything I want, e.g. 
> "format c:"...
> 2) In the second example (with custom class), the custom class is put 
> into an "Applet-Sandbox", I cannot access the local harddisk (a 
> SecurityException is thrown), I cannot open an arbitrary connection, 
> Frames are marked with an "Applet"-Tag in the bottom etc.
> 
> To make it even a little stranger: When I create a FileOutputStream just 
> like before
> 
> var fos = new java.io.FileOutputStream(new java.io.File("somefile.txt"));
> 
> and then use a custom class like this
> 
> var customObject = new Packages.my.own.CustomClass(fos);
> 
> I can do something like
> 
> public void CustomClass(FileOutputStream fos) {
>   try {
>     fos.write(0);
>   } catch (Exception e) {
>     // NO SecurityException will be thrown
>   }
> }
> 
> 
> Well, I think this is not the way it should work. In my opinion, the 
> first approach is ok, because I can also harm the system with JavaScript 
> alone (and I hope it's not a security bug...). Therefore, this approach 
> should also be applied to custom classes, that is, when I use a custom 
> class I don't want any restrictions, no SecurityManagers at all.
> 
> NO SECURTY FOR CUSTOM JAVA CLASSES??
> Yes! The code I'm talking about is part of a Mozilla extension. That 
> means that a user actively and intentionally installed a .xpi file where 
> he/she clicked "ok" to trust it. As said before, by using JavaScript, I 
> can also crash the system in (almost) anyway I want. Thus, I do not see 
> any reason why my code should run in a restricted applet sandbox?
> 
> Thanks for discussing this, or maybe telling me how to handle this :-),
> Keno
> 
> 
> PS: (I put this here to make things not even more confusing...)
> 
> Does anybody tried something like this (using custom classes) before? 
> LiveConnect (Java<->JavaScript interface) exists for a couple of years 
> now, but I heard nobody talk about problems like this before? (In fact, 
> I think that it doesn't work before Mozilla 1.7 at all... see 
> http://bugzilla.mozilla.org/show_bug.cgi?id=246224)
> 
> To get my custom class into the classpath I tried several things. If I 
> use a URLClassLoader in the JavaScript code to load my custom class, it 
> works quiet fine, but I have the mentioned security problems. If I use 
> the Java Control Panel to change the class path by adding something like 
> "-cp=x:\path\to\my\own\CustomClass.jar" to the runtime parameters, my 
> class is also found but has the same problems. When I use 
> "-Xbootclasspath/p:x:\path\to\my\own\CustomClass.jar" instead, 
> everything is fine, I can access the disk, open connections etc. So it 
> seems that the SecurityManager is applied to classes outside the 
> bootclasspath only.
> I can also put my .jar file to the [JRE]/lib/ext directory, because this 
> is also on the bootclasspath as far as I know (some strange 
> MalformedURLException is thrown, but everything is working fine). And 
> [JRE]/classes is working for classes (no .JARs), too.
> 
> So where is the problem? It would be fine if I could change the 
> bootclasspath within the install.js or the javascript part of my plugin, 
> but currently I don't know if this is possible at all and, if possible, 
> if it does work on all plattforms. But anyway (again), this is not the 
> way it should work, e.g. changing the bootclasspath or copy something to 
> the existing JRE-classpath might be something that can be done by an 
> administrator only?!
> 
> I just want my Java code to run without any security restrictions, 
> because there is no reason for doing that :-)

.