Date: Sat, 20 Jul 2013 13:15:05 +0200
From: Michael Schierl <schierlm@....de>
To: Security Explorations <contact@...urity-explorations.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [SE-2012-01] New Reflection API affected by a
 known 10+ years old attack

Hello Adam,


While I (and I assume most of other Java researchers) certainly
appreciate your efforts in making the Java platform more secure, I don't
think it is fair how you try to display yourself as if you were the only
person who was able to find these kind of flaws - you are certainly the
most bragging and egoistic one of those (and online security sites
always happily pick up anything you wrote).

As a researcher who also has reported several (but not 69 yet...) issues
to Sun/Oracle, I think I am qualified enough to comment on some of the
issues you mention.

> We discovered yet another indication that new Reflection API introduced
> into Java SE 7 was not a subject to a thorough security review (if any).

Tell news...

> A new vulnerability (Issue 69) that was submitted to Oracle today makes
> it possible to implement a very classic attack against Java VM. What's
> in particular interesting is that the attack itself has been in the public
> knowledge for at least 10+ years [1]. It's one of those risks one should
> protect against in the first place when new features are added to Java at
> the core VM level. The more surprising it is to discover that Reflection
> API introduced to Java SE 7 didn’t implement proper protection against
> this attack.

If you had a look at the implementation of invokedynamic and the related
java.lang.invoke API (you certainly had), you know that there are
several protections against type confusions in there. However, as you
also know, there have been found and fixed a few type confusion
vulnerabilities already in Java SE 7. And not only in this version; I
took a list of CVEs over the last several years that fixed type
confusion attacks and had a look when they were introduced - almost
every version (1.2, 1.4, 5, 6, 7) introduced some of them, although it
has already been known since at least the 1.1 days. (I think it is
either a coincidence or me not searching hard enough that I did not find
one that was introduced in 1.3). I did not count those but from my
feeling about 20% of all Java vulnerabilities are based on type
confusion attacks.

The reason for this may of course be lack of security review - on the
other hand, these vulnerabilities manifest in several different ways and
only the outcome (type confusion) is the same. Your argument is a bit
about like that burglary is know for centuries, but the current
alarm systems still do not "properly" detect all kinds of that type of
crime (because there are just too many ways to get into a stranger's
house illegitimately).

This will probably be also true for technologies introduced in Java 8
(Project Lambda and Project Nashorn come to my mind here). So if you
really want to help Java Security and have a bit of time to spare, get
one of the Java 8 Early Access Builds and have a look at the new stuff
there, so that the fundamental flaws (if any) can be found and properly
fixed (and not worked around as it is currently happening with some of
the Java 7 flaws due to fear of breaking existing applications) before
it is released.

> Oracle's blog post published on May 30, 2013 [2] implies that maintaining
> the security-worthiness of Java has been Oracle’s priority following the
> acquisition of Sun Microsystems. Oracle's VP goes even further by indicating
> that "acquired product lines [such as Java SE] were required to conform to
> Oracle policies and procedures, including those comprising Oracle Software
> Security Assurance" [3].
> 
> If Oracle had any Software Security Assurance procedures adopted for Java
> SE, most of simple Reflection API flaws along with a known, 10+ years old
> attack should have been eliminated prior to Java SE 7 release. 

Please be fair here. Sun Microsystems has been acquired in 2010, and
Java 7 has been developed from 2006 to 2011. The acquisition has delayed
the Java 7 release already, so I won't infer from the (poor) security
quality of Java to other Oracle products.

This is certainly not limited to Oracle. If you have a look at bug
bounties paid by Google, you will notice that a large percentage of them
was paid to products that have been acquired recently or after some
large new third party code has been added to a product; it is virtually
impossible to review third party code thoroughly enough so that no
vulnerabilities remain.

> This didn't
> happen, thus it is reasonable to assume that Oracle's security policies and
> procedures are either not worth much or their implementation is far from
> perfect.

Here I have to agree. While I base this conclusion on other facts.

Like, within 2013, it happened at least twice that a fix for a security
vulnerability opened up another one; and in both cases it was enough to
see the patch in the OpenJDK repository (with its default 3 lines of
context) without having a look at any other classes to spot the new
vulnerability (and I have never had a look at the changed classes
before). While efforts like JEP 176 will certainly make that kind of
embarrassing mistakes less likely, maybe it is also a good idea to
improve their review process a bit.

> Finally, we published information (and some comment) about CVE numbers
> assigned by Oracle to vulnerabilities reported by Security Explorations
> as part of SE-2012-01 project:
> 
> http://www.security-explorations.com/materials/SE-2012-01-CVE_Map.pdf

I'd like to also comment on two parts of this document:

>>> The Risk Matrices footnotes [3][4][5][6][7][8] used by Oracle for 
>>> most security vulnerabilities reported by Security Explorations 
>>> suggest that these vulnerabilities applied to client deployment of 
>>> Java only and that they could be exploited only through untrusted 
>>> Java Web Start applications and untrusted Java applets.

Historically (even before Oracle acquired Sun) there was a distinction
between two kinds of vulnerabilities in Java.

A) Those vulnerabilities that could only be exploited in scenarios
   where untrusted Java bytecode is executed inside the Java Sandbox

B) Those vulnerabilities that could be exploited in scenarios where all
   bytecode is trusted, but it processes untrusted data (like rendering
   untrusted images, drawing text using untrusted fonts, parsing
   untrusted XML, or opening a SSL connection to an untrusted peer).

Type A has always been called "client deployment vulnerability", and
Type B has been called "server deployment vulnerability", although - as
you already have noticed way too often - "client deployment
vulnerabilities" can happen in shared hosting or RMI scenarios on a
server, and vice versa "server deployment vulnerabilites" can for
example affect a rich client application rendering untrusted multimedia
documents from the Internet.

While I (and most other people who have to administrate ecosystems that
have Java installed) do not really care how these two types are called,
it is quite important for risk assessment to be able to differentiate
these two kinds of bug categories (since we often have scenarios where
there is no untrusted bytecode, but different kinds of untrusted data)
so that we can focus on the important vulnerabilities first.

If you can come up with short names for those two categories that are
more descriptive than the names currently used by Oracle, I am quite
confident they might consider changing their naming terminology.
Removing this distinction, however, will not have any chance of being
accepted.

>>> Oracle’s CVSS score of 0.0 for a Click-2-Play bypass vulnerability
>>> (CVE-2013-1489) may indicate that these types of issues / the
>>> mechanism itself are not that relevant from a security point of
>>> view.

CVSS has not been invented by Oracle, and the CVSS rules make it quite
clear that defense-in-depth fixes that cannot be used to affect
Availability, Confidentiality or Integrity without requiring another
vulnerability are scored 0.0.


Best Regards, keep up the good work and try to be a bit more modest,


Michael Schierl

_______________________________________________
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