Oracle has released Java SE 7 Update 21: eliminating of 45 vulnerabilities, and support for ARM
Oracle (Oracle Corporation) has unveiled the planned corrective release Java SE 7 Update 21, which fixed 42 security problems, as well as a portion of the improvements introduced to increase security. In addition, despite the decision to end the public release updates Java SE 6, as this branch is still actively used, published release Java SE 6 Update 45 with elimination of 25 vulnerabilities.
19 vulnerabilities assigned the highest level of risk (CVSS Score 10.0), implying the possibility of going beyond an isolated virtual machine environment and the initiation of the code in the system when processing a specially decorated content. All of the vulnerabilities present in the JRE.
In addition to fixing vulnerabilities, Java SE 7 Update 21 introduced a series of changes and improvements:
1. Prepared a new package Server JRE (Server Java Runtime Environment), designed to deploy Java-server applications. The package includes a set of tools for monitoring the work of the JVM and perform common maintenance tasks, Java-server applications, but does not include components related to the operation of browser plug-in installer and the automatic installation of updates. The package has been prepared for Solaris, Windows and Linux.
2. Formed JDK for Linux-based systems running on platforms ARM. Supported by the system based on the architecture ARMv6 and ARMv7. In the version for ARM technology is not yet supported Java WebStart, Java Plug-In, Garbage First (G1) Collector, JavaFX SDK and the JavaFX Runtime.
3. Block of the security settings in the control panel (Java Control Panel) is removed and a choice of low-level manual configuration. Security-related settings are now selected based only on the security level. By default, the highest level of security, allowing execution of applets only with verified digital signature.
4. Changed security-related dialogue, any executes in the browser Java-code now leads to the conclusion warning and require explicit user confirmation. Form of dialogue depends on the level of risk: non-hazardous events are displayed minimalist dialogue with the offer click to consent, and for potentially dangerous scenarios, such as running unsigned JAR-files are displayed complex forms that require the user to perform a series of steps.
5. Changes to the RMI (Remote Method Invocation API): default enabled property java.rmi.server.useCodebaseOnly, which prohibits loading external Java-classes to a URL, if the address is not firmly established in the settings. Such a change could lead to disruption of some of the RMI-applications.
6. Changes in Runtime.exec: tightened the rules governing the decoding strings in the way Runtime.exec (String), Runtime.exec (String, String ) and Runtime.exec (String, String , File). There may be problems when executing commands using the incorrect kvoting. For example, Runtime.getRuntime (). Exec (“C: \ \ My Programs \ \ foo.exe bar”) due to lack of space, screening will be perceived as an attempt to execute the command “C: \ \ My” with arguments “Programs \ \ foo.exe “and” bar “, and Runtime.getRuntime (). exec (” \ “C: \ \ My Programs \ \ foo.exe \” bar “) as an attempt to” \ “C: \ \ My”.
7. Commissioned a repository with a black list of certificates and problem JAR-file. Synchronization of client systems with the data from the repository on a daily basis.