Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6548078

The Java Security Model is broken on Windows Vista with IE7 Protected Mode

    Details

    • Subcomponent:
    • CPU:
      x86
    • OS:
      windows_vista

      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 ----------

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                kbr Kenneth Russell (Inactive)
                Reporter:
                ryeung Roger Yeung (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: