Oracle on Tuesday released its quarterly Critical Patch Update (CPU) for April, which addressed a whopping 128 security issues across multiple product families.
Most concerning is that a large number of the vulnerabilities listed are remotely exploitable without authentication, including (4) in its flagship Oracle Database Server, all which can be remotely exploitable without authentication, i.e., exploited over a network without the need for a username and password.
The Critical Patch Update contains 29 new security fixes for Oracle Fusion Middleware, 22 of which are remotely exploitable.
Moving on, the update contains 6 new security fixes for the Oracle E-Business Suite, All remotely exploitable.
While the database giant released 25 new security fixes for MySQL, only (1) was said to be remotely exploitable without authentication.
Oracle also released a Java SE Critical Patch Update to address multiple vulnerabilities affecting the Java Runtime Environment (JRE).
“The Java CPU contains 19 CVEs with CVSS base score of 10 (the highest you can go) indicating that exploiting the vulnerability is not particularly challenging and could give complete control of compromised systems,” said Ross Barrett, Senior Manager of Security Engineering at Rapid7.
“For all of these vulnerabilities, the browser is the vector of exploit,” Barrett said. “For one of those (CVE-2013-1537) some Java server configurations will also be exposed. In total, there are 42 distinct CVEs for Java this quarter, of which 39 are through the Java Web Start plugin and can be remotely exploited without authentication.”
Related Resource: How Secure is Your Code? Test Your Code Here For Free
Other vulnerabilities addressed in this Critical Patch Update include:
• (3) Vulnerabilities in the Oracle Supply Chain Products Suite, (1) which may be remotely exploitable without authentication,
• (11) vulnerabilities for Oracle PeopleSoft Products, (6) remotely exploitable without authentication
• (8) vulnerability fixes for Oracle Siebel CRM, (1) which may be remotely exploitable without authentication.
• (3) fixes for Oracle Industry Applications, none which are said to be remotely exploitable without authentication.
• (18) security fixes for Oracle Financial Services Software, (1) of these which may be remotely exploitable without authentication.
• (2) new security fixes for the Oracle Primavera Products Suite, (1) of these which can be remotely exploitable without authentication.
• (1) new security fix for Oracle Support Tools which is not remotely exploitable without authentication.
Commenting on the Java vulnerabilities, Rapid7’s Barrett reminded how Java exploits lead to the compromise of both Facebook and Bit9 recently, and warned that Java-based threats are not likely to subside anytime soon.
“Administrators and end users alike have to realize that the common wisdom regarding Java plugin security and precautions will not change with this patch, the next one, or the one after that. Java as a web plugin has a lot of unpatched issues, many of which are found and disclosed to Oracle by responsible researchers who are essentially doing Oracle’s Quality Assurance work for free on an ongoing basis,” Barrett said.
“We don’t know how many vulnerabilities the ‘bad guys’ are finding though, until they hit the common market in widespread exploits,” he added. “It’s doubtful that skilled and motivated attackers won’t find the same things as more ethical researchers. And some may well have more resources available to them to look.”
According to Wade Williamson, Senior Security Analyst at Palo Alto Networks, dealing with Java vulnerabilities requires a layered approach.
“The first step is for an organization to understand precisely where and why Java is needed,” Williamson wrote in a recent SecurityWeek column. “Based on the rate of newly discovered vulnerabilities, security teams should assume that Java is and will continue to be vulnerable.” Both Williamson and Barrett, along with just about every security expert, suggest that whenever possible, Java should be disabled in order to reduce risk.
“For many enterprises the rewards of Java have considerably diminished over the years, while the risks are growing exponentially,” Williamson said. “So many organizations will need to take a long, hard look at Java and answer for themselves if it’s worth it.”
Due to the threat posed by a successful attack, Oracle is strongly recommending that organizations apply the security fixes as soon as possible.
“Until you apply the CPU fixes, it may be possible to reduce the risk of successful attack by blocking network protocols required by an attack,” Oracle advised. “For attacks that require certain privileges or access to certain packages, removing the privileges or the ability to access the packages from users that do not need the privileges may help reduce the risk of successful attack. Both approaches may break application functionality, so Oracle strongly recommends that customers test changes on non-production systems. Neither approach should be considered a long-term solution as neither corrects the underlying problem.”
Related Resource: Are Your Applications Secure? Test Your Code For Free
Related Reading: The Unique Challenges of Controlling Java Exploits