Re: [SE-2012-01] Security vulnerabilities in Java SE (details released)

[Security Explorations <contact () security-explorations com>]

Hello All,

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
  Reflection API,
- 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
  future.

Thank you.

--
Best Regards,
Adam Gowdiak

---------------------------------------------
Security Explorations
http://www.security-explorations.com
"We bring security research to the new level"
---------------------------------------------