Oracle outline future Java security plans with extra fixes
Javas steward reveal extra practices to rid the platform of vulnerabilities including extra security fixes, enterprise controls and server side reductions
Oracle’s continuing admission of security concerns within the Java platform shows no sign of letting up, with the news of three extra policies to clampdown on vulnerabilities
Last month, Java’s steward revealed a ‘compromise’ version numbering shakeup designed to make them more reactive to such concerns. Now from October 2013, Oracle pledge to release additional Java security fixes as part of the Oracle Critical Patch Update schedule.
According to the lead for the Java development team, Nandini Ramani, this will amount to four annual security releases, while the company retain the right to issue emergency “out of band” fixes through the Security Alert program.
Given the amount of security problems that have besieged the platform in recent months, more frequent fixes should be seen as a good move, even if it means extra work for IT admins. Since the turn of the year, 97 holes have been closed in the Java platform, far more than the 58 holes in the whole of 2012. Ramani added that by “adopting these stricter procedures”, “Java development significantly accelerated the production of security fixes”.
By implementing new practices and policies, Remani believes the team are better equipped to deal with new vulnerabilities cropping up in the codebase. This is thanks in part to the introduction of additional automated security testing tools, creating a greater scope of source code analysis.
“The Java team has engaged with Oracle’s primary source code analysis provider to enhance the ability of the tool to work in the Java environment,” explained Remani. “The team has also developed sophisticated analysis tools to weed out certain types of vulnerabilities (e.g., fuzzing tools).”
Remani also explains that Oracle has already begun addressing limitations within the browser trust/privileges model, by altering the security for signed applets in JDK 7 Update 21. Now, signing an applet establishes the identity of the signer, but doesn’t necessarily grant them additional privileges. This means that it is possible to run signed applets without letting them out of the sandbox.
The second big change comes in the form of enterprise deployments, with Oracle stating that “Local Security Policy features will soon be added to Java” giving system administrators more control to their own policy.
“The policy feature will, for example, allow system administrators to restrict execution of Java applets to those found on specific hosts (e.g., corporate server assets, partners, etc) and thus reduce the risk of malware infection resulting from desktops accessing unauthorized and malicious hosts,” Remani adds.As for the server side, Oracle will “explore stronger measures” to reduce chances of further problems, by cutting the fat and removing certain libraries deemed “unnecessary for server operation.” However, this won’t be arriving anytime soon as such drastic changes violate existing Java specifications, meaning there’s some legwork yet to see this, and the Local Security Policy, come to fruition.