Let's get critical, critical!
Java SE 7 Update 51 (expires 15th April 2014)
Download (Windows: 32-bit, 64-bit / OS X: 64-bit) / Release Notes / Risk Matrix
January 2014 Critical Patch Update Released
This Critical Patch Update also provided 36 security fixes for Java SE. 34 of these Java SE vulnerabilities may be remotely exploitable without authentication. Only 3 of these vulnerabilities are relevant to Java SE or JSSE server deployments, but are not server side specific (that is they also affect client deployments). The maximum CVSS Base Score for Java SE vulnerabilities fixed in this Critical Patch Update is 10.0. This score affects 5 vulnerabilities (one of them being applicable to server deployments, that is, it can be exploited by supplying data to APIs in the specified component without using sandboxed Java Web Start applications or sandboxed Java applets).
As usual, Oracle recommends that this Critical Patch Update be applied as soon as possible. While a successful exploitation of a number of the vulnerabilities addressed by this Critical Patch Update may not be possible in many customers’ deployments because the affected component is not installed or cannot be easily accessed by malicious attacker, a prompt application of the Critical Patch Update will help ensure that “security in depth” is maintained in the environment. IT environments are dynamic in nature, and systems configurations and security controls (e.g., network access control policies) often change over time. Applying the Critical Patch Update and other vendors’ relevant security patches helps ensure that the related security controls continue to work, should one of the systems fail or its control be circumvented during an attack. (Source)
Well worth being aware that starting in u51 that the lack of a jar manifest permission attribute 'blocks' running of the applet instead of just warning as it did on u45.
A lot of java applications will break as a result of this, contact your vendors for updated applications that have this attribute in place.
The alternatives I'm aware of at the moment are you could use deployment rule sets to whitelist applets, or in dire emergency turning off java security (but we wouldn't want to do that of course!).
DRS is the way to go. Pain to serup though.
I'm looking at setting up the exceptions list to white list the unsigned applets.
However this appears to be a user setting only. I've tried adding a line to my deployment config to specify a system path
here is my deployment config
If the best way to white listing these apps at the system level is a deployment rule set, please point me to a good example.Code:deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties deployment.user.security.exception.sites=file\:C\:/WINDOWS/Sun/Java/Deployment/exception.sites deployment.system.config.mandatory=true
Also it wouldn't be too difficult to copy the exceptions.sites file to each user at logon if that would be the best way to manage it.
Thanks for your input.
I think I have it figured out.
I had to drop the file from my path, and add it to the deployment properties not deployment config
Now create a plain text file named exception.sites and add one url per line according to oracle blog linked above.Code:deployment.user.security.exception.sites=C\:/WINDOWS/Sun/Java/Deployment/exception.sites
A plain text file has to be better to manage than resigning a jar every time I need to add a site to the list.
This solution requires a bit more testing. It was successful on a windows 7 x86 machine.
I hope this helps someone else with their java update.
I've edited my copy of the "exception.sites" file and put it somewhere central.
I need to work out now how to copy this file at logon time to every users folder :
I considered using GPP for this to copy the file at log on, or a log on script.
However you can modify the deployment properties file to tell java where your exception.sites are. See my post #6 above for the line I used.
This will allow you to set the file once for the machine which works nicer with SCCM, you can also use GPP or script at the machine level.
Is it possible to edit the JAVA MSI using ORCA to make the changes such that the "exception.sites" file is stored somewhere else?
I've successfully edited the MSI and added to the properties table the line :
"WEB_JAVA_SECURITY_LEVEL", value = M
Tested and this allows the previously blocked JAVA applet from running, with just a user clearable warning - not ideal, but some progress!
There is a system properties file and a user properties file. That is the default location for the user level properties.
To use the system level properties you need to create a deployment.config file and place it in c:\windows\sun\java\deployment
It should look like this
Then create your deployment.Properties file in the same directoryCode:deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties deployment.system.config.mandatory=true
Here is a snip from my deployment.properties the first one specifies that the exception.sites should be in this same directory.
Code:deployment.user.security.exception.sites=C\:/WINDOWS/Sun/Java/Deployment/exception.sites deployment.browser.vm.iexplorer.locked deployment.browser.vm.iexplorer=true deployment.browser.vm.mozilla.locked deployment.browser.vm.mozilla=true deployment.expiration.check.enabled=false deployment.security.level=HIGH
I don’t know what deployment method you use but here is the batch I use to create the directory and copy the files.
Hope this helpsCode:mkdir %SystemRoot%\Sun\Java\Deployment copy deployment.config %SystemRoot%\Sun\Java\Deployment\ /Y copy deployment.properties %SystemRoot%\Sun\Java\Deployment\ /Y copy exception.sites %SystemRoot%\Sun\Java\Deployment\ /Y
Great, I am sure that will be useful to others too....
I'd almost got there before I left last night but had nt go the deployment.config file sorted...
Also my deployment.properties file had the following lines:
deployment.javaws.splash.index=C\:\\Users\\sadmin\ \AppData\\LocalLow\\Sun\\Java\\Deployment\\cache\\ 6.0\\splash\\splash.xml
deployment.javaws.jre.0.path=C\:\\Program Files (x86)\\Java\\jre7\\bin\\javaw.exe
Tested and deployed to a computer suite.
All working fine now.
Created a startup policy that calls the batch file - thanks for your help!
I will be going down this path tomorrow bright and early.
If anyone could post their deployment.config and exception.sites that would be very helpful to get an idea of what is needed. Id like to remove prompt for updates as well, as with sccm we will manage java releases now.
From what i can tell does the deployment.config reside in the same location as the where the .jar file would be (which is a pain to package) c:\windows\sun\java\deployment ?
There are currently 1 users browsing this thread. (0 members and 1 guests)