Contents
Privileged Java Web Start applications and applets that contain components that are restricted to the security sandbox could potentially be unsafe unless the mixed code was intended by the application vendor. When a program contains both privileged components and sandbox components, security warnings are shown. Note that JavaScript code is restricted to the sandbox and could also cause security warnings to be shown. See Caller-Allowable-Codebase Attribute for information on the manifest attribute for authorizing JavaScript code.
The security warnings state that Java has discovered application components that could indicate a security concern and recommends that you contact the application vendor to ensure that the application components have not been tampered with.
In the dialog, you choose to Block, or Don't Block execution of the application components. You can also click the optional More Information link.
Clicking the Block button blocks potentially unsafe components from running, and the program may terminate. Clicking the Don't Block button causes the application or applet to continue execution with some added protections.
Raising a warning is the default behavior, but there are options available to manage how this situation is handled.
You can manage how mixed code programs are handled via the Java Control Panel. There are four levels of control available.
How to access the Java Control Panel varies for each platform
and sometimes varies for different releases of a platform. On
Microsoft Windows, you can bring up the panel via
Start menu > Control Panel > Java.
In the Mixed Code section of the Advanced Tab, the first three options enable the software protections, but behave a bit differently.
The final option, Disable verification, is not recommended. This option completely disables the software from checking for a mixture of privileged code and sandbox code, leaving the user to run potentially unsafe code with no warning and without the additional protections.
deployment.properties File
The mixed code protection options can also be set by using the
deployment.security.mixcode deployment property, as
described in Deployment
Configuration File and Properties.
deployment.security.mixcode=ENABLE
This option enables mixed code verification. When a potential security risk is encountered, a warning dialog is raised. This is the default value for this property.
deployment.security.mixcode=HIDE_RUN
This option suppresses the warning dialog. The code executes as if the user had clicked Don't Block from the warning dialog.
deployment.security.mixcode=HIDE_CANCEL
This option suppresses the warning dialog and behaves as if the user had clicked Block from the warning dialog.
deployment.security.mixcode=DISABLE
This option is not recommended. The software is disabled from checking for a mixture of privileged code and sandbox code, leaving the user to run potentially unsafe code with no warning and without the additional protections.
This section describes best practices for developers and deployers to protect their applications and applets from being maliciously re-purposed by replacing trusted components with untrusted ones.
Two JAR manifest attributes are available, as of Java SE 6 Update 19, for deploying privileged applications and applets. A warning dialog is not displayed when one of these manifest attributes is included.
Developers and deployers should check their Java Web Start applications and applets to determine if they mix privileged code and untrusted code. If users of these applications and applets may inadvertently download these applications and applets from rogue websites, deploying or re-deploying with one of the following attributes should be considered. Existing signed JARs need to be re-signed after adding these manifest attributes. Note: source code of the classes and resources are not required for re-signing with the manifest entries.
Trusted-Only AttributeFor applications and applets that do not require untrusted
components, use the Trusted-Only attribute.
No warning dialog is displayed and an application or applet
that loads a JAR file containing this attribute does not load any
untrusted classes or resources. This attribute prevents a privileged
application or applet from being re-purposed with untrusted
components. See Trusted-Only Attribute for more information.
Trusted-Library AttributeFor applications and applets that are designed to allow untrusted
components, use the Trusted-Library attribute. No warning dialog is shown and an application or
applet can load JAR files containing untrusted classes or
resources. This attribute prevents components in a privileged
application or applet from being re-purposed with untrusted
components. See Trusted-Library Attribute for more information about using this attribute.
The Trusted-Library attribute is used for calls between privileged Java code and sandbox Java code. If you have JavaScript code that calls Java code, use the Caller-Allowable-Codebase Attribute.
Answer: If you do not use the manifest entries and you encounter the warning dialog when running your privileged application or applet, your program contains mixed code and is affected.
Answer: Test your Java Web Start applications and Java applets against Java SE or Java for Business 6 Update 19 or later. If you are running earlier release families, you should additionally install and test your program under 5.0 Update 24 (or later), or 1.4.2_26 (or later), as appropriate. If you see the warning dialog, then the Java Web Start application or applet contains mixed code.
Answer: End users can click the "More Information" link before deciding whether to click "Block" or "Don't Block" in response to the warning dialog. IT or System Administrators can choose from one of the Mixed Code protection options and configure enterprise desktops through the respective deployment properties described above. Developers and deployers can use the manifest entries to protect their applications from tampering. No warning dialog will be displayed when one of these manifest entries is used.
Answer: Two manifest entries are available to application vendors to deploy, or re-deploy, their Java Web Start applications and Java applets.
Answer: The following releases from Oracle are affected:
Answer: Users will see a warning dialog if a signed Java Web Start application or Java applet contains mixed code regardless of whether it is downloaded from the Internet or Intranet.
Answer: The mixed code issue applies. See the question on applets and applications from the Internet.
Answer: No.
Answer: Please contact your vendor for advice on their implementation.
Answer: Java SE 6 Update 19 (or later) contains the latest security fixes and Oracle recommends that customers use the latest release.
Answer: See the question on testing. In addition, the release notes for each update release documents the latest changes included.
Answer: The following
SecurityException messages are described for
informational and debugging purposes only. The actual message
contents may change between different implementations and
releases.
These SecurityExceptions are thrown when a JAR file
contains one of the manifest attributes and the JAR file itself
contains untrusted components.
attempted to open sandboxed jar "+ url +" as Trusted-Only attempted to open sandboxed jar "+ url +" as Trusted-LibraryThe following
SecurityException is thrown when a JAR
file contains the Trusted-Only manifest attribute
and untrusted components have previously been accessed.
attempted to open Trusted-Only jar "+ url +" on sandboxed loaderThe following
SecurityException is thrown when at
least one JAR containing the Trusted-Only manifest
attribute has been opened and a subsequent attempt is made to load
an untrusted component.
Trusted-Only loader attempted to load sandboxed resource from "+ url"The following two
SecurityExceptions are thrown when
mixed components are first detected and a decision is made to
disallow mixing. In the first case, everything previously loaded was
trusted and then an attempt was made to load an untrusted
component. The second case is the reverse condition.
trusted loader attempted to load sandboxed resource from "+ url" sandboxed loader attempted to load trusted resource from "+ url"The following two
SecurityExceptions are thrown after
mixed components had previously been detected and a decision was
made to allow them to coexist. The exceptions indicate that a
component name collision (resource name or class package name) was
detected between trusted and untrusted components and the request
to load the resource or class was denied.
"resource \"" + name + "\" does not match trust level of other resources of the same name" "class \"" + packageName + "\" does not match trust level of other classes in the same package"The following two
SecurityExceptions are thrown when
untrusted components have been previously accessed, an attempt to
load a trusted component was previously detected, and a decision
was made to allow mixed components to coexist, and a JAR containing
trusted components is opened and a component name collision is
detected between trusted and untrusted components.
"untrusted resource \"" + name + "\" in class path" "untrusted class package \"" + packageName + "\" in class path"
Trusted-Library manifest attribute. Can I sign the JAR
files in the sandboxed JNLP without having to change the JNLP to
request the all-permissions security model?
Answer: Yes, with some limitations beginning
with Java Web Start in Java SE or Java for Business Update 21. The
sandboxed JAR files must be signed in the same way (same signing
certificates) as one or more of the trusted JAR files in a JNLP
file that uses the all-permissions security model, and
the trusted JAR file must be opened by Java Web Start prior to any
sandboxed resource being loaded which shares the same signer. This
means the trusted JAR file must be earlier in Java Web Start's JAR
search order or it is triggered to load independent of the simple
search order by use of the JAR indexing feature. In Java Web Start,
the main application JNLP's JARs are searched first, followed in
declaration order by any JNLP extensions. JAR files labeled within
a JNLP as "eager" are searched first, followed by "lazy" JAR files,
followed by any JAR files labeled as using the "part" feature.
Answer: No, Java ME is not affected.
