|Another Java 7 Security Flaw|
|Written by Alex Armstrong|
|Thursday, 25 April 2013|
Oracle recently issued its April Critical Patch update, but a new serious security flaw has been discovered that affects the new Server JRE as well as all versions of Java 7, including the latest update.
The new security problem, Issue 61, concerns the Reflection API and was uncovered by Adam Gowdiak an experienced Java Virtual Machine hacker who is founder and CEO of Security Explorations based in Poland.
Having sent a vulnerability report and a proof of concept, i.e. code of an exploit exposing the weakness, to Oracle, Gowdiak sent an email to the Full Disclosure Mailing list outlining the new flaw that can be used to achieve a complete Java security sandbox bypass on a target system.
Referring to Oracle's Secure Coding Guidelines, Gowdiak advises that following software components and APIs as potentially prone to the execution of untrusted Java code:
He also expresses concern, as reflected in the email's the subject line "Yet another Reflection API flaw affecting Oracle's Java SE" that it is this particular API that is the culprit:
In Apr 2012 we reported our first vulnerability report to Oracle corporation signaling multiple security problems in Java SE 7 and the Reflection API in particular. It's been a year since then and to our true surprise, we were still able to discover one of the simplest and most powerful instances of Java Reflection API based vulnerabilities. It looks Oracle was primarily focused on hunting down potentially dangerous Reflection API calls in the "allowed" classes space. If so, no surprise that Issue 61 was overlooked.
Security Explorations numbers security flaws sequentially and maintains a Vendors status log indicating the response received from, in most instances, Oracle although some of the Issues have concerned Apple and IBM. The latest entry, dated 24-Apr-2013 reads:
This leave two others, Issues 54 and 56, currently outstanding.
In general Oracle has responded quickly to notifications of vulnerabilities. Issue 54 was one exception. Oracle's delay in investigating the issue, and then ruling that it wasn't a security bug, stating:
"obtaining a method handle for a protected method from a superclass is allowed behavior"
led to Security Explorations going public with details of the exploit.
In respect of Issue 56, which originates in the Bytecode Verifier and provides the potential to create a valid class that does not call an inaccessible constructor if its superclass, the log records:
[Oracle's] analysis backs the claim that Issue 56 demonstrates the behavior not forbidden by the JVM specification.
Does this mean that is is a bug or allowed behavior? Luckily we can rely on Security Explorations to thrash out this matter.
To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin, or sign up for our weekly newsletter.
or email your comment to: firstname.lastname@example.org
|Last Updated ( Thursday, 25 April 2013 )|