Been using Java for a number of years, but the recent warnings about zero-day exploits concerning the JRE are troubling.
I am considering the following approaches (all on a Windows 7 Ultimate/64 bit machine):
Disabling Java in all browsers (long since done)
Uninstalling Java outright (and hence removing C:\Windows\System32\java.exe, java2.exe, and javaws.exe)
Downloading the Java JRE & JDK into another volume (F:\Java64\jdk1.8\jre), and having all java dependent apps (eclipse, minecraft, etc.) point directly to it.
The questions I have are:
Will this prevent most if not all java centric malware?
Can I configure the java updater to update the java JDK/JRE in F:\Java64\jdk1.8\jre) without having it reinstall into C:\Windows\System32 behind my back?
Desktop Java was never really a vector for malware, the browser plugin was. So disabling it in browsers should suffice. Moving it to another volume or deleting the files from %Windir% will not change anything. Uninstalling does pretty much the same as disabling the browser plugin.
The runtime (and the JDK, for that matter) does not need to be installed in order to use it.
I recommend the following:
make a copy of the JRE, somewhere new, or perhaps one per dependent app
uninstall it
check your browser(s) for plugins and delete/disable them if they got left behind
delete the java.exe files in %windir% if they get left behind
do not point the PATH or any environment variables at a copy of the JRE
While removing or disabling the browser plugin may be sufficient, I personally wouldn't trust that it will remain removed or disabled. The Java automatic updater, for example, might inadvertently reinstall them.
Of course, doing this means that you don't get automatic updates. But Java security issues that affect legitimate programs are rare.
Related
i have noticed that signed applets are loaded much slower with the latest plugin (included in java 8u31 and 7u75). I have debugged the situation quite a lot and i found out that the problem is directly related to the size of the jar files that are referenced in the jnlp file. The problem is that each time the applet starts, there is some 're-indexing' of the cached jar files that takes time.
To reproduce the issue i did this:
I created a minimal applet and in the jnlp file i used to deploy it, I added several irrelevant .jar files (that are not even referenced, so the classloader does not load them) of considerable size (e.g. 30MB). Of course i am using versioning in the jnlp and capture all http traffic to make sure that the delays are not because of traffic (either re-downloading or certificate revocation checks, etc). I run the applet with the trace enabled and then went through the xml trace log file and found out where the delays come: they are always from the JarSigningVerifier ....
Has anyone else seen something like that?
It is very easy to see and reproduce this behavior and i wonder if there is something i am overlooking. Having worked on applets for the past years extensively, i am totally lost at what can be happening. I can verify that reverting to the previous version of the plugin (and every other version before) works as expected.
I have submitted a bug report with oracle, but i haven't heard back still. Any info or idea will help,
TIA
Same here. I thought already I'm getting crazy. Thanks for sharing this.
We are using Java Web Start, but it's sharing the same problem of re-indexing all jar files (in our case it's an app with quite some jars, so starting takes ages).
Aside from the fact that Oracle suddenly decided to check the certificate of the deploy TLS, which caused some hickup on Linux and Macs (we used a StartSSL certificate there, which isn't included in the Java keystore - on Windows it works as it uses the platforms root certs, too).
And, to make it even worse, on Windows x86 the 8u31 silently dies if -XX:+DoEscapeAnalysis or -XX:+OptimizeStringConcat is present in the JVM arguments, though both parameters are standard in Java 8 (but not in 7, that's why they've been included, still). The 64bit engine doesn't have that problem.
The next thing they changed is they now overwrite the start icons if they've been changed (we changed them to put the 64bit engine's path in there), so it stubbornly changes the path back to the 32bit engine every time.
The behaviour of Oracle is not helpful at all, as they didn't announce any of these changes in their changelogs, let alone announcing the certs changes a few days ahead.
I would like to hear from anyone who's sharing the problems and possible workarounds.
Patric
Have you been able to solve this issue? Have you had a reaction from Oracle?
UPDATE START
I've tried everything I can think of and haven't managed to solve the
issue, so I posted my own question on this issue.
A similar bug report can be found here and is backported to at
least Java 8u51 which I tested. Yet again they managed to increase
startup time for our application.
END UPDATE
We are using Java Web Start for an Eclipse RCP-based application with jars that are all signed.
Startup time is 8s within the IDE, Java version doesn't seem to matter here. With web start the story is different. It becomes (much) worse with every Java update:
7u?? (<60): +2s (10s)
7u60: +5s (13s)
7u75: +15s (23s)
8u31: +12s (20s)
8u40: +21s (29s)
8u51: +23s (31s)
Have you tried your jnlp without versioning? In my experience Java jnlp is very buggy specially if you change the jnlp default values. Versioning support is disabled by support, so try it without versioning and see if it still slow?
For me, I noticed some bugs when I used update="background" value, so I no longer change the default update method. My theory is that Oracle only tests jnlp against default values before they release new Java versions.
Last night a new Java 7 update has been released: 7u65. I have a web application where a service applet is loaded, and after the update, my tests on different PCs did not show issues nor wrong behaviors.
Later, I started to receive issue reports related to my product's Java service applet. All the reports came from users who updated Java JRE to 7u65 (from 7u60):
The applet was not loading at all. I display a "Loading" screen when the application starts, and this was not being displayed. Also, all the services provided by my Java applet were unavailable.
After changing the Java Control Panel's advanced configuration to always show the console (in one of the PCs where this issue happened), I discovered that the applet was not even launching the Java console.
Using the same station where the error happens, trying to access java.com to check the current java version, the Java applet is loaded and the console is displayed without errors.
All tests were performed after clearing Browser and Java Cache, and even after removing the installed certificates (mine is a valid signed applet).
I checked the Java 7u65 release notes and none of the mentioned changes seem to affect my applet. Also, there were no issues while using Java 7u60.
I don't have any clues about what is going on, perhaps because the java update was released hours ago. As the Java console can not be displayed even if I configure Java Control Panel to do so, I can not tell if there is any exception. I can not reproduce the issue in my PCs (Windows 8, nor Windows 7, both at 64 bits), but the issue has been reported on Windows 7 PCs.
One of my friends told me that this seems to be happening on machines where Java 7u60 was in use, and then it was updated to Java 7u65 with no deinstallations. Also, this tends to happen in older OS (ie: WinXP) which is more natural.
I write this question because it seems very odd that some PCs have this issue, and some others not. I'd like to know if any one else is having this issue, knows what could be the reason, or has discovered/applied any solution to it. Also, I'd like to share the solution if I ever happen to find it.
Thanks.
Edit:
External references, related to the same Java version (JRE).
Internet Explorer crashing after updated Java to 7u65: An issue with the same JRE version, this time with Internet Explorer and Firefox.
RS Loading Issue (Java) ~ READ: An issue related to the same JRE version update, this time, in a Java Game.
The future of Java on Windows XP:
This end of support announcement has been misread as "Java no longer works on Windows XP" or "Oracle will stop Java updates from being applied on Windows XP". These statements are not correct.
I just ran into this exact problem with one of my applets.
It looks like some changes were made to the handling of the 'java-vm-args' and 'java_arguments' params in 7u65.
'java_arguments' seems to no longer work, when it is specified, my applet will silently fail without even launching the JVM.
I have had the same problem.
I delete C:\Users\${USER}\AppData\LocalLow\Sun
When i reloaded the web page containg the appelets. The JRE recreated this folder again.
And evrything was OK.
There is no big difference between the folders contents .. but it worked.
It seems to be a bug in the jRE
It seems that oracle has changed something with processing default plugin java arguments,
that caused problem in new java.
When upgrading from older version of java it is possible that value for
deployment.javaws.jre.0.args (or deployment.javaws.jre.1.args)
is not defined in
C:\Users\${USER}\AppData\LocalLow\Sun\Java\Deployment\deployment.properties
If you add
deployment.javaws.jre.0.args=
to deployment.properties, applet will work.
It can be done through Java Control panel also:
Java -> View -> double click on Runtime Parameters cell for java 7u65 to enter edit mode -> OK -> Apply
java-jvm-args solution didn't work for me, applet was launched but arguments were ignored.
Oracle has released an update that resolves this specific issue via version 7u67
http://www.oracle.com/technetwork/java/javase/7u67-relnotes-2251330.html
As Miloš Ratković wrote, if customer hasn't string in deployment.properties
deployment.javaws.jre.X.args=
where x is number of java installation for version 7_65 (number of java installation for particular version is X in string deployment.javaws.jre.X.product=1.7.0_65), Java applet failed to start.
For my case I have a solution - don't pass any arguments for my applet.
In my javascript code for starting applet I'm just comment
<param name="java_arguments" value="some arguments">
string
Also, if you delete the directory C:\Users\${USER}\AppData\LocalLow\Sun, during next startup of java applet java write new deployment.properties with correct java args string
Uninstall java 7 update 65 and reinstall java 7 update 55 Download the windows x86 offline version
Go to Java control panel and uncheck: automatic update
When the next window comes up, click on "do not check"
then click on "apply" and "ok"
close all browsers and reopen them to continue your work
This has worked for me every time so far and I have been doing this for the last two weeks now with "0" issues.
Sorry, this is not the answer. I was trying to verify the feedback about JRE 7u65 not able to accept "java_arguments"; however, I setup a Windows x32 and installed (new) 7u65 without upgrade from any older version. With the "java_arguments", the machine is able to load the applet in IE8 and FF30, when few specific PCs do fail the same applet with upgraded u65.
I have a long standing domino application that uses embedded views to display data. This application has been moved from a server 2003, 32 bit, domino 8.5 environment to a new server 2008 R2 64 bit domino 8.5.3 FP6 environment.
I have everything up and working as before with the exception of embedded views. They are giving a SecurityException "Missing required Permissions manifest attribute in main jar: http://*.com/domjava/nvapplet.jar".
I have confirmed that the actionbar.jar, editor.jar, nvapplet.jar, and outline.jar are the current version on the server. I have even replaced them with the version from the IBM download (http://www-01.ibm.com/support/docview.wss?uid=swg21662233).
I can get this to work by displaying the view as HTML instead of Java Applet, but I don't understand what the issue is with the java version?
There were major security changes to Java in relation to applets. You can download the latest applets here.
http://www-01.ibm.com/support/docview.wss?uid=swg21662233
You may need to clear your browser cache if it still persists after that.
[update] The question now mentions that you installed Fixpack 6, installed the Jars then uninstalled Fixpack 6.
When you uninstall a fix pack, it reverts the files it touches back to what they were before the fix pack was installed. Although I have no details on it, it is quite likely that the updated security applets were also added to fix pack 6 (as it's the last fix pack for R8.5.3).
So during the uninstall the applets look the same as FP6 and it reverts them.
To solve this, after the revert you would need to drop in the updated applets again.
If the issue still persists at this point, you need to open the Java Console on your browser and update your question with the logs it generates (as it pertains to the error).
Turns out this situation may have been a little unique, but I will post it here for future reference in case anyone else runs into this. The server was a fresh build of windows and domino all the way up to 8.5.3 FP6. The FP6 installer date stamps the jars in question with the install date of the system. So in my case I had people come to the site, download the jar with a file date newer than 1/17/2014, which is the date of the files IBM put in the fix mentioned above. Those files are a simple flat copy so they always maintain the 1/17/2014 date. Anyway, any user that came and picked up the newer date files 3/1/2014 for example would keep those files or rev date in their local java machine cache and ignore the 1/17/2014 file I had replaced them with, thus they continued to show the problem. Only by manually clearing their cache from the java were they able to pick up the 1/17/2014 file and no longer have the issue.
Actually from what I was told via IBM FP 6, does not include the fixed .jars. That was my main problem assuming it did.
I am deploying a signed & trusted applet. We need to run the applet in a separate JVM & increase the heap size. Setting separate_jvm & java_arguments works on our local boxes. Curiously we have clients that though they are using 1.6.0_15 don't seem to be running the new plugin architecture.
When I check their Java config, "use next-generation plugin" is checked & IE7's option "use Java 1.6.0_15 for applet plugin" is also checked. Nothing seems obviously wrong. The Java console also reports the correct version, but neither separate_jvm nor java_arguments are respected.
Just as a sanity check we wrapped the applet in a JNLP & set up our web page to serve the applet with a jnlp_href. The applet tag had a bogus code parameter to ensure the JVM was actually running the JNLP. The Java console complains that it cannot find the bogus class when it should be properly loading the JNLP.
Are there security settings or something else that might cause what I'm seeing?
I'm afraid I've just a few suggestions rather than an absolute answer.
The Java virtual machine version
and plug in version can be
different. Go to Control Panel,
Java, Runtime Environment settings.
When you check the console it may
show the two different versions.
The new plugin architecture would
depend on browser, Opera doesn't use
it at all, for example. IE7 does
though. So check which browser it
works on.
Java has got corrupted due to
repeated installs and uninstalls.
Pretty common complaint I've found.
If you have control over one of the
machines you should uninstall every
Java. Restart machine. Install
latest Java.
The swing-UI of Java-programs doesn't work perfectly together with the awesome-wm. awesome is a window-manager for UNIX, that automatically resizes program-windows, and the Swing-UI doesn't recognize these resizes correctly. I don't care if awesome or Java is guilty, what I wanna know if I can change my Java-programs in a way, that they will work with awesome. So that users of my programs get the correct experience, even when they use exotic window-managers.
Easiest workaround - get wmname from suckless and use it to set the name of the window manager to LG3D:
wmname LG3D
98% of the time this will fix the issue.
From the man page of awesome:
BUGS
Of course there´s no bug in awesome. But there may be unexpected behaviours.
Java applications which use the XToolkit/XAWT backend may draw grey windows only. The XToolkit/XAWT backend breaks ICCCM-compliance
in recent JDK 1.5 and early JDK 1.6 versions, because it assumes a reparenting window manager. As a workaround you can use JDK 1.4
(which doesn´t contain the XToolkit/XAWT backend) or you can set the following environment variable (to use the older Motif backend
instead): AWT_TOOLKIT=MToolkit
You might find that this is a similar problem to that experienced with using Compiz and Java (on Ubuntu at least), but I am guessing.
The fix for this (taken from here) is to add the following environment variable to your program:
AWT_TOOLKIT="MToolkit"