mailing list archives
Re: [SE-2012-01] Security vulnerabilities in Java SE (details released)
From: Security Explorations <contact () security-explorations com>
Date: Tue, 20 Nov 2012 11:02:16 +0100
We have updated our project details page and added selected Proof of
Concept codes to it that have been developed as part of our Java SE
security research. They are available for download from SE-2012-01
project details page. Those willing to better understand Reflection
API based abuses and our technical report should find them helpful.
Also, we would like to clarify the following:
- CVE numbers used by Oracle and IBM may not necessarily correspond
to our bug numbering scheme. The four CVE numbers used by IBM seem
to reflect all 17 issues we reported to the company. It looks IBM
counted the number of different insecure Reflection API calls, not
the number of different locations these APIs were actually used at.
- IBM phrasing referring to 17 reported issues as "potential security
vulnerabilities in Security Manager" can be now verified by running
our Proof of Concept codes under vulnerable versions of IBM Java.
As of the primary conclusions coming from our research, we would like
to emphasize the following:
- generic techniques used to bypass Java in 2012 were discovered 7
years ago, but they have never been published before,
- the problems are around Java stack inspection security model and
- Java bugs are not only about web browsers - they can be exploited on
servers too (i.e. buggy RMI protocol, XML Beans deserialization),
- Java 7 looks less secure than Java 6 - certain Java 7 features seem
to have less security by design,
- The existence of multiple security issues in new Reflection API from
Java 7 indicates that it didn’t go through a security review,
- Other vendors such as IBM had no idea about security implications
of Reflection API (really simple cases of Reflection API flaws),
- The existence of not-yet-patched (proved to be easy to patch in 30
min. time) Issue #50 tells a lot about the quality of Oracle’s
vulnerability evaluation / patch testing processes (a bug in a code
addressed not so long ago),
- It looks software vendors do not have an easy life with Oracle. Quotes
from our Inbox:
"They are no help (even when "alleged security vulnerabilities" are
being exploited by malware kits/etc.)"
"We'd like to be able to protect our customers…You're the only guys
that can help on this (Oracle certainly won't)"
"There's a lot of politics. Hint: 'Oracle unbreakable Linux'"
"I know others have pushed Oracle, nothing has or will happened"
- Certain design / implementation choices can affect security of a
technology for years and lead to dozens of bugs (50+ security fixes
related to Reflection API in Java SE so far),
- Vendors not following their own Secure Coding Guidelines / not
learning from past mistakes do not give a bright prospect for the
"We bring security research to the new level"