Message-ID: <50AB5528.9080301@security-explorations.com>
Date: Tue, 20 Nov 2012 11:02:16 +0100
From: Security Explorations <contact@...urity-explorations.com>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Subject: Re: [SE-2012-01] Security vulnerabilities in Java
	SE (details released)


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"
---------------------------------------------

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists