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  customer  (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  customer .

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 ----------
Posted Date : 2007-04-19 17:59:23.0

N/A

"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.
Posted Date : 2007-06-20 18:15:57.0

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.
Posted Date : 2007-07-20 19:38:54.0

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.
Posted Date : 2007-11-08 03:06:56.0

We (ADP Lightspeed) are having a similar issue with DEP and IE7(mshta.exe) calling an applet on Vista. We have a Microsoft case number SRX070305603739. Based on what they are saying we need to talk Sun to resolve this.

Ditto. We too have been using signed applets for years with few problems, and nothing on this scale. If this is not addressed as a severe defect very soon (weeks) I will have to begin plans to abandon applets in our product ASAP, at considerable cost.

That is true, its broken

I totally agree. Java's signed applets are the answer to trusted, portable code in a web environment. This worked very well up until Vista, and also on other platforms (Mac, Linux). I definitely think Sun should fix this.

Well, it's been a month now, 55 votes and in the Top 25, but not even a "we're looking into it" from Sun. Looks like non-toy applets may be officially dead soon. Let the rumors begin...

I'd have to concur with the bug complaint to a large degree.

On the other hand, I have to say that IE7+Vista's behavior is totally onerous.  It is truly a shame that consumers and IT folk insist on using IE rather than Firefox.

If Sun really does have the ability to circumvent the IE7 security limitation, then I would be baffled and perplexed if they do not do so very soon. The problems that this will cause applet developers and the money that will be lost due to service issues and re-development of existing working applets will be off the charts. If I were an executive at Sun I would make this my number one task!

We have a NAC solution pushed to nearly 4000 users and are pushing it to another 5000 at the end of the month and this bug is killing us...

The team I work with has developed a solution to this problem using an IE broker.

It is technically feasible to implement this solution in a short period of time.

I was also faced.

An update from Sun on this issue would be appreciated.  Signed applications are pretty much useless on Vista unless this is addressed.  Customers may not be willing to turn off IE7 protected mode to fix this issue.

I concur with the other posters.  Our development of full fledged applets will die a quick death if this is not fixed pronto.  We pay Verisign to get a signing certificate, and this certificate is not gaining us any functionality for a growing percentage of our user base.  Can someone from Sun at least drop a note to say they are actively working on this, and whether it is just a policy issue, or if there is a technical difficulty?

Though my previous comment bemoans IE usage, etc, the fact of the matter is that loads of people use IE and as other posters have said, this puts serious limitations on applets.

My understanding from other bug reports is that Flash has already long since worked around this.  If Sun can't address this, their other recent and noteworthy efforts to resurrect may come to naught.

I meant to say "resurrect Java in the browser" in the comment just above.

Given the latest evaluation note from Sun an ETA for an out-of-process plug-in for Windows would be *very* helpful.  At JavaOne it was stated that this was being targeted for Java 7 with some *possibility* of appearing in a Java 6 update.  It would seem that anything short of a Java 6 update shortly after the "Consumer JRE" update will fall way short.

Hi,

I do not know if this is relevant here but maybe it can help someone.
We run into the same problem: we have a signed applet that must run at the highest privilege level under windows vista. We found a solution but it is not pure java. 
Let say we want to run the program P.exe at the highest level from a signed java applet.
In our solution, java starts a first C# program. This program is in charge of creating a process running at the highest privilege level. There are many examples of this on the web (see for example http://www.wintellect.com/cs/blogs/jrobbins/archive/2007/03/27/elevate-a-process-at-the-command-line-in-vista.aspx
This may be not enough because usually you want Java to interact with the process P through standard input and standard output. It just happens that under windows vista, when an elevated process is created, the parent process can not access the standard input/output streams of its children process if the parent process is not itself running at the highest privilege level.
A solution is to use another process that will run at the highest privilege level and forward the standard input/output to the java applet through an IPC. This is in fact the solution described here (in a C++ context): http://www.codeproject.com/useritems/UAC__The_Definitive_Guide.asp But in the previous link, the author uses named pipe as IPC and this is not very well supported in Java. We have used a socket that accepts connections only from the local computer.
So in short, in our approach, the java signed applet creates a first C# process. This first process starts and elevates a second C# process. This second process runs at the highest privilege level. It opens a socket with the signed java applet. Through the socket, the java applet tells the second C# process that P.exe should be executed. The second C# process starts P.exe and redirects the standard input/output streams to the signed java applet through the socket.
If you are interested, please go to http://www.fileslost.com : you will see the applet running. By the way if you need to recover a file, this is a great site. (we intend to improve the GUI offered by the applet now). Under vista, you will see that the user gets prompted but that if the user accepts the prompts, the applet runs just fine. Do not be afraid regarding the certificates: we have no money to buy certificates stamped by a true certification authority so we are using self signed certificates.
I do not think that a pure java solution can be designed in the current situation. For example, the C# code uses runas to do the elevation and there is no equivalent in Java.
I hope this helps. 
Best regards.

Marc

For all concerned, it is likely that this bug will be addressed in Java SE 6 Update N (Consumer JRE)

http://www.javaworld.com/javaworld/jw-10-2007/jw-10-consumerjava.html

"close to 100% compatibility" is not acceptible. With the new applet model, will applets still be able to commincate with Java script in the browser page they were launched from? What are the compatibility shortcomings?
In any case, this bug should not be closed until the fix for it has been released. Sorry, but this is not a duplicate of 6622332, but associated/addressed by the same fix. This is very questionable bug management.

I think you need to read "duplicate of N" as "is/will-be resolved by N". It just means "see N for further action and status" and that nothing more will be put here. In this case 6622332 is taking over for a couple dozen bugs, it seems, and it's still open.

Not quite clear, but it looks like the new plug-in isn't available for "us" yet. Time to watch 6622332.

Hi,

I do not understand very well why Sun closed this bug.
It is said: "For all concerned, it is likely that this bug will be addressed in Java SE 6 Update N (Consumer JRE)".
Does Sun really believe that all computers with the current java plugin under windows vista and IE7 will update their JRE just because Sun decided to acknowledge the problem described in this bug?
I think the answer is no.
For example, the jre on some vista computers is installed by oem and then sent to customers that only have a RTC connection. I believe that these users (e.g. my parents for example) will not update the JRE.
As we can not assume that all java applet users will update their JRE, we have to live with the half broken signed applet execution model of the java plugin 1.6.0_01.
That's just my thought. I would like to hear some comments.
Thank you.

Marc

@Marc - I don't think Sun bothers about that - once a broken piece of software is out on the market there's no way to fix all of  it - you can only fix the next versions.

Any chance we can get a defined range for N?

6uN will be 6u10. We will very likely not have all of the updates between the current one (4) and 10, but skip a few. The thing which is best defined is the schedule, which can be seen at the top of:
https://jdk6.dev.java.net/6uNea.html

Would this fix be back propogated to Java SE 5.0 soon? My company has many Java-based products and we are not planning to upgrade to SE 6.0 until sometimes in 2009, but we are trying to support Vista/IE 7 by the end of 2008.

I am currently using Version 6 update 13 of Java Plugin in Firefox 3.0.8 MS Vista environment.  I am still experiencing the same behavior described for this bug even though the status of the bug has been flagged as "Closed".  

To clarify, behavior is that I am unable to write files to "protected" directories even though all permissions have been granted to applet.

Has this issue really been fixed or has this bug been mislabeled?