United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6548078 The Java Security Model is broken on Windows Vista with IE7 Protected Mode
JDK-6548078 : The Java Security Model is broken on Windows Vista with IE7 Protected Mode

Details
Type:
Bug
Submit Date:
2007-04-19
Status:
Closed
Updated Date:
2010-05-11
Project Name:
JDK
Resolved Date:
2007-11-08
Component:
deploy
OS:
windows_vista
Sub-Component:
plugin
CPU:
x86
Priority:
P2
Resolution:
Duplicate
Affected Versions:
6
Fixed Versions:

Related Reports
Duplicate:
Duplicate:
Relates:
Relates:

Sub Tasks

Description
FULL PRODUCT VERSION :
Java Plug-in 1.6.0_01, Java Plug-in 1.6.0_02-ea

ADDITIONAL OS VERSION INFORMATION :
Windows Vista

EXTRA RELEVANT SYSTEM CONFIGURATION :
Internet Explorer 7 with Protected Mode ON

A DESCRIPTION OF THE PROBLEM :
Entrust products distribute signed applets but when we run them in Internet Explorer 7's default configuration on Windows Vista it runs at the low privilege level which inhibits their functionality.  We feel that this behaviour is inconsistent with the Java Security Model.  On all other platforms, once the user has accepted the security trust dialog for the signed applet then the applet has full access to the system.  This has always been the Java Security Model and it is not acceptable for this Security Model to be limited in this fashion now.

As a result, we (Entrust) do not have a satisfactory explanation to provide our customers regarding the behavior Java 6 exhibits on Vista; it is surprising to us that Sun claims Java 6 to be a fully supported JVM on Vista when the Java Security Model is so obviously broken.   These limitations are mentioned in the release notes, but this is not an acceptable solution.  We have been in communication with Microsoft (MS ID# SRX070214601787) in an attempt to resolve this and they claim that there is no way for me to elevate my applet's privilege level unless Sun collaborates with MS to provide applet producers a solution.  They feel that Sun should provide a solution, specifically that "Java might have some solution via the run time library that is installed locally on the user machine."   Since the Java Plugin does have an installer it should give itself the necessary registry entries for the COM Elevation Moniker, and therefore be able to provide the necessary functionality to load the applet with elevated permissions when the applet is properly trusted.

It is within Sun's power to fix this problem, and it is also Sun's responsibility.  Your customers have invested vast amounts of time and money developing solutions using Java technology with the understanding that the Java Security Model is standard on all flavours of Windows and all operating systems.  To suddenly introduce the caveat that end user's cannot run their applets in Vista with Protected Mode is a violation of this understanding.  We have an applet that is deployed to millions of users worldwide in G2C and B2B environments and transparency is a very important key feature of the product.  Aside from Vista, Entrust's signed applets have worked (for over 7 years now) with the default browser configuration on many OS platforms, and we have never encountered such a central issue with the applet trust model with any other OS. Turning off Protected Mode on Vista or adding the website to IE7's Trusted Sites list are unacceptable solutions to Entrust since they break the zero-configuration feature inherent to our applet products.


This is not and Enhancement Request, this is a Bug.  This is not a limitation that can be taken lightly if Java would like to continue to be considered an industry leading cross-platform web technology going forward.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create some CAPI certs in the windows MY cert store.
Open index.html in IE7 on Vista with Protected Mode OFF
Open java console and notice that your aliases printed out.

Open index.html in IE7 on Vista with Protected Mode ON
Open java console and notice that "Access is Denied"


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
After the user accepts the Trust Dialog the signed applet should be able to write this file and have full system access as exhibited in other flavours of Windows, MacOs and other OSs.
ACTUAL -
After the user accepts the Trust Dialog the signed applet is restricted by the browser's low privilege level and is very limited in its operations.  The applet is limited in its write access to the file system, registry and CAPI Cert Store which is in contradiction with the Java Security Model.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
This code is taken from example code in Leveraging Security in the
Native Platform Using Java SE 6 Technology
(http://java.sun.com/developer/technicalArticles/J2SE/security/ )

Demo Applet code:
 
            KeyStore store = KeyStore.getInstance("Windows-MY");
            System.out.println("Created keystore");
 
           // PROTECTED MODE CAUSES A KEYSTOREEXCEPTION WHEN I CALL LOAD
HERE
            store.load(null, null); 
 
            Vector certificateVector = new java.util.Vector();

            for (java.util.Enumeration e = store.aliases();
e.hasMoreElements();) {

              String alias = (String) e.nextElement();               
              System.out.println("Alias:" + alias);
            }
        } catch (Exception e) {
            System.out.println("Caught Exception" + e);
        }

---------- END SOURCE ----------

                                    

Comments
EVALUATION

"On a Windows OS other than Windows Vista, when running a signed applet, a user is prompted with a security warning dialog box and must respond. If "Yes" is clicked, the applet will have AllPermissions to run on the user's machine. This includes permission to write/delete a file from the local disk.

On a Windows Vista OS, this is no longer true. Instead, AllPermissions is limited to Java Applet scope, not Windows scope. Because a process running in IE has a low integrity level, it will not be able to write/delete a file from a medium/high integrity level directory. "

We are going to look at IE broker process or COM Elevation Moniker to make it work.
                                     
2007-06-20
EVALUATION

Based on the current Plugin architecture and discussion with Microsoft, both COM elevated moniker and Broker process won't work with Plugin. The only workaround in short term for customer is to turn off "Protected Mode" in IE browser, or add their website into IE "trusted site".

We are working on a out-of-process model for plugin, once it is done, it will solve this issue as well.
                                     
2007-07-20
EVALUATION

A new implementation of the Java Plug-In has been developed which changes the execution model of applets. Instead of running the applets in a JVM embedded in the web browser's process, they are now run in a separate JVM process which communicates back to the web browser. This work was checked in under 6622332. We have received confirmation from outside customers that the new plug-in solves the fundamental problems of running signed applets on Windows Vista. There are certainly still bugs to be fixed in the new plug-in to attain close to 100% compatibility with existing content, but the main problem has been solved.

As of this writing the new Java Plug-In is not yet the default, but will at least ship side-by-side with the current one in the forthcoming "6uN" release, for which early access builds can be found at https://jdk6.dev.java.net/6uNea.html . The new plug-in will be initially available in the forthcoming build 08 barring unforseen circumstances.

Closing this bug as a duplicate of 6622332. Once the new plug-in is available, please try it and file any issues against it under product java, category java_plugin, subcategory plugin2.
                                     
2007-11-08



Hardware and Software, Engineered to Work Together