invoking System.exit() from signed applet crashes browser

RESOLVED WORKSFORME

Status

Core Graveyard
Java: OJI
RESOLVED WORKSFORME
16 years ago
7 years ago

People

(Reporter: Adam Megacz, Assigned: Joshua Xia)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [jpibug], URL)

Attachments

(1 attachment)

3.78 KB, application/octet-stream
Details
(Reporter)

Description

16 years ago
See the attached URL for an example; grant your trust to the applet, then close
the applet's window (which will cause the applet to call System.exit()), which
will (incorrectly) crash/quit the browser. This happens on 0.9.9, Win32 and
Linux. I'm posting this with Galeon, which is why the browser detection doesn't
match up.

The correct behavior would be to unload the jvm plugin .dll/.so and reload it,
restarting the jvm plugin rather than the entire browser.

Comment 1

16 years ago
Works for me ! Using JRE 1.4.0 and Mozilla 2002033109 under WinXP.

Comment 2

16 years ago
More info : when I close java window, it closes also Mozilla !

Comment 3

16 years ago
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

16 years ago
Patrick -- any suggestions on this one?
Assignee: beppe → beard

Updated

16 years ago
QA Contact: shrir → pmac

Comment 5

16 years ago
Need a stack crawl. Reassigning to Sun engineer.
Assignee: beard → joe.chou

Comment 6

16 years ago
Browser exits because java plugin exit 
(and pipe to browser side is closed, etc.).

This is jpi problem because applets should not be allowed to 
call System.exit() in any circumstances. See item 11 of 
java security faq 
  http://java.sun.com/sfaq/.

Steve - looks like this your area.

BTW, moving to OJI.
Component: Plug-ins → OJI
Whiteboard: [jpibug]
(Reporter)

Comment 7

16 years ago
> This is jpi problem because applets should not be allowed to
> call System.exit() in any circumstances. See item 11 of
> java security faq: http://java.sun.com/sfaq/

Hrm, doesn't it mean that *untrusted* applets shouldn't
be able to do that? The test case is a signed applet which (AFAIK)
should run with full permissions (provided it wraps dangerous
calls in doPriviledged()'s)

Also, the link above is for jdk1.1 (see the first paragraph),
which had a totally different security architecture. If I recall
correctly, the distinction between applets loaded off the
filesystem vs applets loaded off the network was erased in jdk1.2
(both are untrusted unless signed and approved by the user).

To increase the confusion level even further, check out point #13:

> applets loaded via the file system are allowed to exit the
> virtual machine

Which directly contradicts #11:

> In particular, this means that applets can't invoke some
> program to list the contents of your file system, and it
> means that applets can't invoke System.exit() in an attempt
> to kill your web browser.

Quite confusing! =)

Is there an updated Apple Security FAQ for jdk1.2+? If so, perhaps
we could go by that.

Comment 8

16 years ago
I do not think there is an updated FAQ because this one is referenced 
from java plugin documentation. 

Personally i do not fill System.exit from (signed or not) applet 
should not work because it not just exits jvm of this applet 
because _same_ jvm is used to run other applets in other windows.

(Reporter)

Comment 9

16 years ago
> Personally i do not fill System.exit from (signed or not) applet
> should not work because it not just exits jvm of this applet
> because same jvm is used to run other applets in other windows.

Hrm, how else can an applet force all of its classes to unload?

The main concern is that there should be a way for an applet to ensure
that if the user visits the applet a second time, without closing the
browser, that all classes are reloaded and all class initializers are
re-run.


Comment 10

16 years ago
xiaobin: may be you can clarify what is expected behavior here?

Comment 11

16 years ago
I believe the same rule against applets invoking System.exit() still applies.
System.exit() is defined to call Runtime.exit(). The specification for
Runtime.exit() makes it clear that the SecurityManager has a right to deny the
call to Runtime.exit() (and transitively, System.exit()) _for any reason_. Also,
all applets are required to run under a security manager.

This means that the Plug-in's security manager can refuse all calls to
System.exit() and be well within the specification.

If you think about the architecture of Sun's plug-in and the specification of
Runtime.exit(), you will see that it doesn't make sense to allow applets to call
Runtime.exit (System.exit()). That is because Runtime.exit() is defined to shut
down the _entire_ JVM, not just exit the application (applet). Sun's plug-in is
designed to run all applets in a single JVM. That means, at a minimum, you would
terminate _all_ applets on all web pages with a single applet's call to
System.exit(). On Windows, the JVM is designed so that it will only terminate
once (after the browser has stopped).

Furthermore, the applet security documentation states that applets aren't
allowed to manipulate threads outside their threadgroups. Obviously, terminating
every thread in the JVM is well outside this rule.

Note also that the documentation doesn't distinguish between signed and unsigned
applets when defining the behavior described above. The restrictions apply
regardless of whether the applet has been signed. It is analogous to the servlet
specification: even a servlet in a signed Jar cannot call System.exit() (they
can't even create threads!).

So, in conclusion, the Sun JPI's security manager should be throwing a
SecurityException from Runtime.exit()/System.exit() whenever it is invoked by an
applet.







Comment 12

16 years ago
I have created a simpler testcase with source code.

Building the tests:

javac *.java
jar -cf SystemExitApplet.jar *.class *.html *.java
jarsigner -storepass anyany SystemExitApplet.jar tstkey

(assuming you have an alias "tstkey" in your keystore with password "anyany")

Running the tests:

Download the testcase (SystemExitApplet.jar).
Run "jar -xf SystemExitApplet.jar" to extract the HTML pages and source code

Test A: 1. Open SystemExitInit.html in Mozilla.
        Grant permission for the session when Mozilla asks you to.
        Expected result: SecurityException (see console)
        Actual result:   All Mozilla windows and all applet windows close.
                         The mozilla process has terminated.

Test B: 1. Open SystemExitButton.html in Mozilla. 
        2. Grant permission for the session when Mozilla asks you to.
        3. Click the button.
        Expected result: SecurityException (see console)
        Actual result:   All Mozilla windows and all applet windows close
                         The mozilla process has terminated.

The HTML pages are included inside the signed JAR file. 

The same behavior occurs in Internet Explorer 5.5 also.

I tested on JPI 1.4.0 / Mozilla 2002042608 / Windows 2000 SP2

Comment 13

16 years ago
Created attachment 82167 [details]
SystemExitApplet.jar

Comment 14

16 years ago
Notice that the applet doesn't have to be signed, if it is run from local
filesystem.

I'm also experiencing crashes when accessing the System.exit() applet which is
not signed. You can test it at
http://olo.office.altkom.com.pl/domowa/mozilla/system_exit/ .
Just visit the page and click on the link to SystemExitTestApplet.html.
The crashes are reproducible with win32 trunk build 2002060908 running on
Windows 2000.

My applet is a very simplified testcase, you can find the source in the JAR
archive. It simply calls System.exit(1); from its init() method.

Updated

16 years ago
QA Contact: pmac → petersen
(Assignee)

Comment 15

15 years ago
reassign to me
Assignee: joe.chou → joshua.xia

Comment 16

15 years ago
WFM on Linux(RH8.0)/Windows2000 mozilla1.2 JRE1.4.1_01
I got following exception in my java console:
=========================
java.security.AccessControlException: access denied (java.lang.RuntimePermission
exitVM)
	at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:270)
	at java.security.AccessController.checkPermission(AccessController.java:401)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
	at java.lang.SecurityManager.checkExit(SecurityManager.java:762)
	at java.lang.Runtime.exit(Runtime.java:88)
	at java.lang.System.exit(System.java:713)
	at
pl.com.altkom.office.olo.Testcases.SystemExitTestApplet.init(SystemExitTestApplet.java:5)
	at sun.applet.AppletPanel.run(AppletPanel.java:347)
	at java.lang.Thread.run(Thread.java:536)
=======================
So, I think this has been fixed in latest JRE.
Closing
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Updated

7 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.