Full Disclosure mailing list archives
Re: [SE-2012-01] New Reflection API affected by a known 10+ years old attack
From: Michael Schierl <schierlm () gmx de>
Date: Sat, 20 Jul 2013 13:15:05 +0200
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/
Current thread:
- [SE-2012-01] New Reflection API affected by a known 10+ years old attack Security Explorations (Jul 17)
- Re: [SE-2012-01] New Reflection API affected by a known 10+ years old attack Jeffrey Walton (Jul 20)
- Re: [SE-2012-01] New Reflection API affected by a known 10+ years old attack Bob iPhone Kim (Jul 20)
- Re: [SE-2012-01] New Reflection API affected by a known 10+ years old attack Jeffrey Walton (Jul 20)
- Re: [SE-2012-01] New Reflection API affected by a known 10+ years old attack Security Explorations (Jul 20)
- Re: [SE-2012-01] New Reflection API affected by a known 10+ years old attack Georgi Guninski (Jul 22)
- Re: [SE-2012-01] New Reflection API affected by a known 10+ years old attack Florian Weimer (Jul 22)
- Re: [SE-2012-01] New Reflection API affected by a known 10+ years old attack Bob iPhone Kim (Jul 20)
- <Possible follow-ups>
- Re: [SE-2012-01] New Reflection API affected by a known 10+ years old attack Michael Schierl (Jul 21)
- Re: [SE-2012-01] New Reflection API affected by a known 10+ years old attack Security Explorations (Jul 20)
- Re: [SE-2012-01] New Reflection API affected by a known 10+ years old attack Jeffrey Walton (Jul 20)