Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=240152987
"This critical patch update contains 42 new security vulnerability fixes," said Oracle's prerelease announcement. Furthermore, a whopping "39 of these vulnerabilities may be remotely exploitable without authentication, i.e., may be exploited over a network without the need for a username and password."
"Due to the threat posed by a successful attack, Oracle strongly recommends that customers apply critical patch update fixes as soon as possible," said the advisory.
According to Oracle, the update will address security vulnerabilities in Java 7 update 17, Java 6 update 43, and Java 5 update 41, as well as prior versions of each. Although Oracle officially retired Java 6 in February, announcing that it would no longer be updating the software, its most recent emergency Java patch, released March 4, included security updates for not only Java 7, but also Java 5 and 6.
[ Who are you going to call when DDoS attackers come gunning for you? Read Spamhaus DDoS Attacks: What Business Should Learn. ]
In the face of criticism over rising numbers of Java vulnerabilities and related attacks -- leading to the Department of Homeland Security earlier this year advising users to avoid using the Java browser plug-in whenever possible -- Oracle pledged to squash Java bugs more quickly, and appears to be following through. Notably, the company released the out-of-band Java 7 update 11 in January, Java SE 7 Update 13 and Java 7 update 15 in February, and Java 7 update 17 on March 4, just before the annual Pwn2Own contest.
What changed since then? As of March 8, Michael Horowitz, who maintains the Java Tester website, counted 12 unpatched bugs in Java 7 update 17. That count included four zero-day Java exploits demonstrated at Pwn2Own, including a heap overflow vulnerability employed by French vulnerability seller Vupen.
According to veteran Java bug hunter Adam Gowdiak, CEO and founder of Poland-based Security Explorations, the Java update will fix six vulnerabilities his company has identified, the oldest of which was discovered and reported to Oracle on Jan. 18.
With the new Java 7 update 21 set to be released Tuesday, Oracle will also implement previewed Java Control Panel changes, which include revised security controls for users of the browser plug-in. "All browser-based Java content (applets and applications) will present additional information and require confirmation before being allowed to run," said Oracle.
That change will be backed by new warning messages including a yellow warning triangle with a warning for any application "that cannot be identified because the certificate is untrusted or expired." Meanwhile, a yellow warning shield and text will flag any application that "is unsigned and/or the certificate is not valid," saying that the application's certificate "should not be trusted."
The new version of Java 7, aka the Java Runtime Environment (JRE), will also eliminate a user's ability to fully disable the Java security controls. "We are also removing the 'low' security settings in the Java Control Panel (e.g., low/custom), to prevent users to from inadvertently opting-out entirely from the security remediation we are building into Java," said Oracle. "Users will be better protected by maintaining up-to-date versions of the JRE on their systems, combined with requiring code that is signed by a trusted Certificate Authority (rather than self-signed or unsigned code)."
Oracle has been warning developers that the security changes might break some existing Java applications and encouraging them to get their applications signed by a trusted certificate authority before Tuesday.
Security experts also expect Oracle to lock down how Java handles digital certificate revocations, after security researcher Eric Romang in March reported discovering "a german online dictionary infected by g01pack Exploit Kit" that was targeting users with a malicious Java app. Interestingly, the Java browser plug-in was registering the certificate used by the malicious app as being trusted, even though the certificate had been revoked by GoDaddy in December 2012.
Obviously, the failure of Java installations to clock revoked certificates is a problem. But that risk is arguably exacerbated because earlier this year, Oracle altered the default security level in Java to the "high" level -- defined as "you will be prompted before any unsigned Java app runs in the browser" -- to better block silent exploits. Despite the German online dictionary serving up a malicious Java application, however, it was being silently run on any Java installation with a default security setting. As a temporary fix, changing Java's security settings to the "very high" setting wouldn't identify the revoked certificate, but would at least require user approval before executing any Java app that exploited the vulnerability.
InformationWeek is conducting a survey to determine the types of measures and policies IT is taking to ensure the security of the full range of mobile assets on cellular, Wi-Fi and other wireless technologies. Take the InformationWeek 2013 Mobile Security Survey today. Survey ends April 19.