Keeping users on Internet Explorer up-to-date and secure

Oracle actively works with many vendors on Java security and an important goal is finding ways to remove old and unsecure Java versions from circulation.   Oracle recommends that Java users keep their JRE installations up to date with the latest security baseline through the Java Auto Update feature. Microsoft Windows users have long been able to  improve the security of their computer by checking for old versions of Java and removing them using the Java Uninstall Tool.

On August 6th, Fred Pullen and Jasika Bawa from Microsoft announced, on the Internet Explorer Team Blog, that Internet Explorer will soon block out-of-date ActiveX controls.  On August 10th, Microsoft updated their their blog with more technical information, timelines and pointers to more resources for developers and sysadmins.

This Internet Explorer feature will provide Internet Explorer users with notifications when web pages try to load out-of-date Active X controls, like Java ActiveX controls provided by a JRE below the security baseline [1].  Additional documentation and information and how to configure and manage this new Internet Explorer feature are provided by Microsoft.

At Oracle, maintaining the security-worthiness of Java is our priority.  As in this case with Microsoft, we continue to work together with our partners to keep Java users up-to-date and secure across different browsers and operating systems.  Enterprises that need to keep an older JRE around for legacy applications should still use a current JRE installed along the older JRE and leverage the Deployment Rule Set Functionality to limit access to the older JRE to well-known applications

 - Don 

Comments:

You publish an update one day, that addresses every internet user. Than you find out that company user have a problem the other. Than you release an update the third closing comments on the blog post, but refer to the one that you describe by name of the authors and link to it. This is kinda destrubctive, while you talk of "partners".

Posted by guest on August 11, 2014 at 04:02 PM PDT #

Can anyone help with this??

c:\dev\GEAC\Extensity\Rel8_3>java URLContent
java.net.SocketException: Permission denied: connect at java.net.DualStackPlainSocketImpl.connect0(Native Method) at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source) at java.net.AbstractPlainSocketImpl.connect(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at sun.net.NetworkClient.doConnect(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.<init>(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown
Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(Unknown Sou
rce)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Sour
ce)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown S
ource)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown So
urce)
at URLContent.main(URLContent.java:18)

If the program is compiled and ran using Java 7, there’ll be no error.

Posted by guest on August 18, 2014 at 09:25 AM PDT #

We are using Deployment Rule Sets to limit access to the older JRE to well-known applications like you stated - but are running into a problem.

One business critical applications has the following properties (*s to protect info):
title: Enterprise Services Repository
location: null
jar location: http://app.*.com:52400/rep/repository/*.jar
jar version: null
isArtifact: true

The application downloads a .jnlp file, and uses java web start to execute.
Since the location is null, this application cannot be targeted by a location rule. And the certificate hash method only works when the application is cached (being ran more than once). If cache storing is off, which is the case in some situations, how can this application be targeted? Or at least told to run with an older JRE on start?

Thanks!

Posted by guest on August 18, 2014 at 01:21 PM PDT #

Let's head over to a discussion site like https://community.oracle.com/community/java or http://serverfault.com/ to look at the deployment rule sets. I think more people will benefit from those vs. this comments section. (post a link once the question is up there)

Posted by costlow on August 20, 2014 at 09:38 AM PDT #

DRS question is posted here:

http://serverfault.com/questions/622850/drs-unknown-jnlp-location

Thanks!

Posted by guest on August 20, 2014 at 11:42 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

Science Duke
This blog contains topics related to Java SE, Java Security and Usability. The target audience is developers, sysadmins and architects that build, deploy and manage Java applications. Contributions come from the Java SE Product Management team.

Search

Categories
Archives
« February 2015
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
18
19
20
21
22
23
24
25
26
27
28
       
       
Today