Google App Engine Java security sandbox bypasses | Hacker News Reader

Google App Engine Java security sandbox bypasses

seclists.org

92 pointstshtf23 comments

It a pretty fair assumption to expect the Java runtime itself to be in an OS-level sandbox, Google would never treat that much native code as the last layer of security.

The App Engine CPython runtime can also be subverted in a variety of ways, but about the most exciting thing you can trigger here is for the process hosting your code to immediately be killed.

Google have a very good track record in security and that's the reason why GAE-J is my system of choice. I am ignorant on their bounty offerings though, but I would have assumed Google are state of the art there. Can someone fill me in on the background and intentions of Security Explorations?

Security Explorations is a well-known security research company. Most of their research is related to Java.

See:

* http://www.security-explorations.com/en/SE-2011-01-press.htm...

* http://www.security-explorations.com/en/SE-2012-01-press.htm...

* http://www.security-explorations.com/en/SE-2013-01-press.htm...

* http://www.security-explorations.com/en/SE-2014-01-press.htm...

Just JVM things.

Can somebody explain me why GAE does not use virtualization as a security layer? Xen is a powerful, free, mature product that utilizes clever techniques along with hardware support to provide the best isolation layer yet available. AWS EC2 runs just fine on Xen, GAE seems to have lots and lots of hiccups.

GAE appears to be an evolution of Google's internal platform which does not use virtualization. Why invest in learning about a technology that is very different from Linux when such knowledge would not benefit 99% of Google's workloads? Given the number of kernel developers at Google, if they want security I would expect to see them improve Linux rather than adding virtualization.

Of course, Google now has virtualization (GCE) because some customers demanded it, but if GAE already works there's no reason to redesign it.

For whoever downvoted:

This post is accurate. AppEngine-the-PAAS uses containerization for resource control and as a security layer on top of the (J)VM security.

GAE-the-EC2 competitor uses virtualization to segment machines. The Google Docker offering uses Docker containers, and segments each customer into a VM.

It is somewhat correct to say that it's an evolution of the internal platform, as in that it indeeed used the same mechanisms to spawn jobs; but in the way it provides a PaaS it was very much a parallel track - instead of naming and allocating the different backend instances you just get all of them in a box.

What makes you think it doesn't?

Well, that would be a lot of redundancy. Good isolation is hard to achieve (as proven by this post), why bother doing it twice? Is there any upside?

AppEngine (the PAAS) uses containerisation to isolate services. That both provides a security layer and allows resource control.

This incident demonstrates the need for it.

Additionally it isn't really redundant. AppEngine supports Python and Go as well as Java, and it makes sense to have a common isolation infrastructure.

Defense in depth. Have another failsafe if your first line of defense fails (as it will).

When GAE launched they were only charging for the actual CPU time used by the application. There was no static monthly fees on running your app on GAE.

If you are not getting money when the app is not performing tasks, you need to minimize the costs related to that state. Two ways to minimize the costs: 1)put as many apps as possible to singe machine 2)implement a fast mechanism for loading/unloading the apps based on demand.

Xen like virtualization is not best choice for this purpose. Virtual machines have overhead which limits on how many of those you can put on one server. Even if the app running on VM does nothing, you still have the overhead. Also starting up the VM takes time so reacting to demand is slower. At least the original GAE would quite often shutdown the application completely and only start it when a new web request came in.

What makes you think they don't?

What makes you think it isn't?

Keep in mind that Oracle is one of the companies actively working with NSA as per some of the Snowden leaks. I trust anything java based not at all. (on the more practical side)

"Never attribute to malice that which is adequately explained by stupidity."

-Robert J. Hanlon

Seriously, it's probably an issue with the Java Security Manager. This will no doubt help the JVM community be better.

More accurately, Google's implementation of the Java Security Manager. The JVM running on GAE is modified by Google. This is why there is no Java 8 on GAE and probably never will be. It is a metric ton of work for them to port their changes to each new JVM release.

Managed VM's are the new direction because now you just install the latest Oracle or whatever VM you want. https://cloud.google.com/appengine/docs/managed-vms/

> This is why there is no Java 8 on GAE and probably never will be.

Do you have sources for this? Java 7 on GAE took really long and eventually shipped only shortly before Java 8 was released. From history I would expect the same to the case for Java 8 on GAE. It will take years and ship around the time Java 9 is released. OTOH if Google created a maintenance horror for themselves by patching the fuck out of the JDK and Jetty (I don't think Servlet 3 is ever going to happen) I don't really have many sympathies for them.

No, I'm just reading the writing on the wall. I'm just paying attention to things as I run a business on GAE.

They didn't have such a strong focus on GCE and managed VM's before. It is clear with the release of the public beta of managed VM's, they want people to really test it so they can get it out of beta as quickly as possible. I imagine that most of the team that was allocated to work on GAE is now working on GCE and managed VM's.

I'll be switching to managed vm's at some point in the near future (when I can find some time for it). They are also less expensive, which is nice.

That quote is useful only for helping the obviously guilty avoid punishment.

I specifically thought that might be the case as I was posting, so apologies for the useless comment. I should have listened to my conscious on that one.

That being said though, allow me to take the opportunity to express the utter disdain and contempt I have for the reference of Hanlon's razor. First off, any rule that uses the word "never" is already probably going to be wrong most of the time. Secondly, there are innumerable instances where stupidity would work in place of malice despite the fact that it was actually malice. I see it used almost exclusively by apologetics of some sort or another. It's a useless straw man of a logical fallacy not conducive to intellectual debate.

It's official, Hanlons razor should be put into retirement and not used by anyone with a respect for logic and rationality.

I agree. It's a fun quote and has humor value, but it's the exact wrong stance to take when thinking about security.

Stupidity is one of the most commonly used disguises for malice.

Reply on news.ycombinator.com