Java 7 update 11: Insecure version prompt with upgrade button
We recently deployed Java 7 update 11, now that 13 was released we have been getting tons of calls on the below dialog (dialog pops when going to a java page):
This seems like a new dialog/update path that we do not want. We manage java, the users should not install it.
I know this is tied to the security changes in Java, that is another issue we know about and know how to manage but the above prompt does not seem disable-able at least not globally.
I have found that this dialog adds some registry values:
HKCU\Software\JavaSoft\DeploymentProperties...
deployment.expiration.decision.10.11.2=later ("never" seems to work as long as you put it in the deployment.properties file and delete the registry key so it reloads when java control panel is launched)
deployment.expiration.decision.suppression.10.11.2=fale (true will remove prompt but again tricky since the java control panel will over-write on some occations...).
What really worries me is that these settings are tied to a specific version of java (10.11.2=7 update 11). I worry that the next release will change the entries (say to 10.13.2=7 update 13) and any disabling will be for naught.
I I I cannot find any official documentation on those regkeys or the dialog. Anyone run into this?
I have found only one other referrence to this on the web, it is on Oracles own site... no solutions there but more info:
https://forums.oracle.com/forums/thread.jspa?threadID=2488735&tstart=0
I
-
I'm up against the same wall. My company has many applications that have Java dependencies and each needs to be tested prior to deploying a new Java version/update. Oracle forcing a new update on us is generating a lot of complaints from users. - adaml 11 years ago
Answers (2)
See the Security Options and Control Settings in the below link
http://docs.oracle.com/javase/7/docs/technotes/guides/deployment/deployment-guide/properties.html
Comments:
-
Thanks for the link, though there are settings to manage other dialogs none effect the dialog and upgrade prompt above.
While we can force the "deployment.expiration.decision.10.11.2" settings with deployment.properties file, the settings both in registry and in the users file are over-written when the java control panel is opened/used. I suspect the settings propagate from deployment.properties file to registry just as a generic action but the settings themselves are not fully supported like others (other documented settings in deployment.properties file will over-write registry, the settings noted above do not, there seems to be a default automatically applied both to users file and registry. Not only that but the 10.11.2 referenced in the setting is version specific, the setting will change as soon as another security related update comes out. - dandirk 11 years ago
Right, wrong, or indifferent - here's my "fix". Seems fairly stable and gets rid of most of the popups. For now at least. http://www.labareweb.com/java-1-7-auto-update-deployment-with-sccmmdt/
Comments:
-
I commented on your blog... It is nice but even you own tests suggest it isn't rock solid. From what I have seen those settings will get overwritten on the next scheduled baseline check OR when you open the Java Control Panel applet which seems to immediately perform the baseline check. - dandirk 11 years ago
-
Yep, agree. This is one I am ready to give up on and take my chances with 1.6. I am interested in what changes if you check the box "dont notify me until the next version is available" and "dont ask me again" on the application permission popup. I've run registry tracers, and can't find anything related. I even tried your comment on deployment.expiration.decision.10.15.2=later and
deployment.expiration.suppression.10.15.2=true and it eventually failed again.
Unreal isn't it? Something within Java itself must be sending out the commands for this. - bretthexum 11 years ago-
Yeah totally... I think I am seeing exactly what you are with some success and odd failures... At one point I added the full reg keys deployment.xxxx.10.13.2=later and the other one true. The moment I run the control panel applet it would get overwritten. Tried direct reg edits and deployment.properties file.
What I was seeing is that if you put the setting in deployment.properties file, it will propagate to the user reg hive location but won't appear in the users deployment properties file... This I sort of expected since other supported settings don't ever appear in the users file (like security level). The moment you run the java control panel it overwrites the reg AND the users deployment file.
Then I expanded to include the couple of date entries, pretty much added all user reg keys (after checking box and hitting later) to the admin deployment file... This worked, and I just started to remove entry after entry until it didn't... didn't happen.
The only regkeys I saw edited when clicking on those boxes were in the same deployment.properties key we have already been looking into. Maybe a file/ini is edited somewhere that tells java not to overwrite????
oh I was on crack about the multiple regkeys versions... Thankfully those unique version numbers in the regkeys are related to the version installed and NOT the newest version. That would mean if we every figure it out, that one setting should be good until you package release a new version updating those keys to the new version #. - dandirk 11 years ago
-
I've updated my post with the messy fix. We're actually looking at group policy to push out the files in the security folder to all users (existing profiles + new profiles) rather than try to script something and modify the default user. It may not work, but worth a test. - bretthexum 11 years ago
-
Using GP to push to user profiles do not work. - Timanator 11 years ago
-
Group Policy preferences, sorry - bretthexum 11 years ago
-
Did that work for you? we have a small testing group and the users still get the Java is Insecure prompt at random when accessing sites requiring Java. - Timanator 11 years ago
-
It did for the most part... until the next version of Java came out and overwrote the files. It's not pretty. With group policy preferences the files only come down at login - so if a user sits for 3 days and then Java releases an update - the files will get overwritten. Then, at next login, back to normal (sometimes). I am so sick of Java.... this is beyond ridiculous. - bretthexum 11 years ago
-
Oracle have released a build of Java that does not, by default, display the message that the JRE is below the security baseline. It needs to be downloaded from the Oracle support site not the public release download page. From what I understand, the special build contains binaries that have the baseline check code omitted:
Handling the New JRE Security Dialogs (Doc ID 1553875.1)
Starting with 7u25, the version of the JRE with auto-update off (see support note 1470691.1) does not, by default, display the message that the JRE is below the security baseline. Users who need to suppress this warning should use that version of the JRE. It is recommended that only enterprises with other mechanisms for keeping the JRE up-to-date use this build.
Support Note: Java Auto-Update (AU) Policy Change (Doc ID 1470691.1)
JRE builds with auto-update turned off, previously available only to customers of Java SE Advanced and Java SE Suite, can now be downloaded for free from the Java SE Downloads page.
(I found the hard way that the public download page version still has the expiration date feature, If it changed system clock to April 25, 2059 the insecure message still showed, but I downloaded from the support site link and it supressed the expiration date with the same test.) Link:
https://support.oracle.com/epmos/faces/PatchResultsNDetails?_afrLoop=247344574904963&patchId=16631990&_afrWindowMode=0&_adf.ctrl-state=h4jacbsbd_157
Please read the following before using the JRE build with auto-update turned off:
•The JRE build with auto-update turned off is available only for the Windows 32-bit platform, because the auto-update feature is not available on any of the other supported Java platforms.
•It is critical that desktops are always kept up to date with the latest security releases. The easiest way to handle this is to use the standard Oracle binaries and let the default auto-update mechanism handle this for users. If you have a desktop management solution in place and prefer to have more control over when and how updates are pushed out, you can use the auto-update-disabled binaries and provision updates through that system instead. - medo007 11 years ago-
How does one go about gaining access to that link. I created an account but it says I do not have access to downloads. If I attempt to gain access, it tells me to contant my Customer User Administrator. - dbekas 11 years ago
