We wanted to verify whether security and privacy of users' data and applications is properly implemented in the environment of an arbitrary cloud service based on a Java VM runtime.
We also wanted to find out whether security issues similar to those discovered in Java SE software were present in other vendors' code.
We treat it as complete. Google made it possible for us to complete the project. The company enabled our suspended account and we were able to verify and test our ideas / codes in a GAE environment again.
We have high respect to Google for this move and truly appreciate it. If Google wouldn't let us complete the work, we'd have wasted months of research.
Google's move makes it possible for all parties interested in a security of Java and Java cloud based solutions such as PaaS to benefit from the results of our work (it makes contribution to the field possible).
We found multiple issues that allow for a bypass of certain GAE security restrictions such as the whitelisting of JRE classes and/or a complete escape of a Java VM security sandbox.
We haven't reached a point in our research where we could state that arbitrary compromise of other GAE user's data or applications is possible.
Almost all vulnerabilities found are specific to the GAE environment. None of the implemented, complete Java security sandbox escapes affect Oracle Java software.
We used a minor issue in Oracle Java code to implement a given instance of a JRE classes whitelisting escape (Issue 2), but it was evaluated by Oracle as not affecting Java SE.
We also discovered a partial security bypass issue in Java SE 7 code, which was accepted by Oracle (Issue 42) and demonstrated a complete GAE Java security sandbox escape with it.
Issue 42 can be exploited in a straightforward way in GAE environment, because Google decided to change a standard Java security model for it (allow for custom Class Loaders in particular). As a result, it was possible to access full functionality of these objects (i.e. define privileged classes without any restrictions) and disable Java security mechanisms for the GAE environment.
Beside illustrating the pitfalls associated with custom Java Runtime modifications applied by the company to security sensitive Java APIs and components, Issue 42 also showed that Google mitigations aimed at preventing the exploitation of JRE flaws were not working as intended.
Yes. Discovered security issues violate "Secure Coding Guidelines for the Java Programming Language" . They also illustrate very known risks related to Java security .
They could be used to gain a lot of information about the JRE sandbox itself, Google internal services and protocols.
They also seem to be a potentilly good starting point to proceed with attacks against the OS sandbox and RPC services visible to the sandboxed Java environment.
We are not aware of any such communication. In that context, we are the only source of information to the public regarding these issues.
Over the last 6 years of our activity we have found dozens of security issues that affected hundreds of millions of people (just to mention Oracle Java flaws) or devices (security issues in STMicroelectronics' set-top-box chipsets).
We have never received any reward from any vendor for our work and we didn't expect any reward this time either. But, we have received a reward from Google. More on that can be read here
It's worth to note that Google rewarded Issues 1-27 reported to the company in Dec 2014. The company also issued two additional rewards for the vulnerabilities reported in the first half of 2015 ($20000 for Issues 28, 31-34 and improperly fixed Issue 2 and $30000 for Issues 35-39 and 41). As a result, the total amount of rewards issued by Google for security vulnerabilities discovered in GAE environment has reached $100000.
Yes. All vulnerabilities' details and Proof of Concept codes have been published here.