JDK-6643379 : Filter out insecure JVM command-line arguments from deployment.properties
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-12-18
  • Updated: 2010-09-08
  • Resolved: 2008-03-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10 b10Fixed
Related Reports
Relates :  
JDK-6642995 - Revise Java 2D-related secure properties
Relates :  
JDK-6629341 - Plugin2: Backward Compatibility issue after secure properites check is introduced
Relates :  
JDK-6644200 - Regression: race condition in first JavaScript-to-Java call causing intermittent failures
Description
There are some signed applets that overwrite deployment.properties to add JVM command-line arguments for various purposes, whether it is to increase the default heap size for applets or to turn on or off Java 2D acceleration properties. In the new plug-in, if there are any non-secure JVM arguments in this list, the JVM instance will not be allowed to run unsigned code.

There are some applets (see the Comments section for details) which are specifying invalid system properties. Because these aren't in the known good list of secure system properties, this basically causes the new plug-in to fail to launch any untrusted code, which is unacceptable.

We need to filter out insecure JVM arguments from the list specified via deployment.properties. With the new plug-in, developers now have a workaround for this, which is to specify these arguments via the new java_arguments applet parameter.

The other option we considered (under 6629341) was to treat all of the arguments specified in deployment.properties as trusted. This does not appear to be an acceptable solution on the Windows Vista platform, where deployment.properties is in a low-integrity location. Having different treatment of arguments specified in deployment.properties on different platforms would be confusing so we are not choosing this option.
Comments
EVALUATION After implementing this solution it was pointed out that this breaks the ability to debug applets by specifying command-line arguments like -Xdebug -Xrunjdwp in the Java Control Panel. This will be fixed under 6629341.
02-01-2008
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6643379.3 testcase: http://web-east.east.sun.com/deployment/www/tests/1.6.0_10/6643379/
19-12-2007
EVALUATION Allowing specification of insecure JVM command-line arguments for all applets via deployment.properties is very problematic. At a minimum we would need to trust such settings, but we can not do so on the Windows Vista platform, where deployment.properties is stored in the low integrity directory and can be overwritten by arbitrary untrusted ActiveX controls. We also do not want to have the handling of deployment.properties be platform-dependent. Changed the JVMManager to filter out non-secure JVM command-line arguments from those specified in deployment.properties. Developers can specify these on a per-applet basis via the java_arguments applet parameter if necessary.
19-12-2007