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.

Gowdiak writes: 
What's interesting is that the new issue is present not only in JRE Plugin / JDK software, but also the recently announced Server JRE as well.

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:

• Sun implementation of the XSLT interpreter
• Long Term Persistence of JavaBeans Components,
• RMI and LDAP (RFC 2713)
• Many SQL implementations

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:

• Oracle confirms Issue 61. The company informs that it will be addressed in a future Java SE Critical Patch Update.

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.