[HN Gopher] I Hacked Google App Engine: Anatomy of a Java Byteco...
___________________________________________________________________
I Hacked Google App Engine: Anatomy of a Java Bytecode Exploit
Author : arkadiyt
Score : 170 points
Date : 2021-05-06 15:34 UTC (7 hours ago)
(HTM) web link (blog.polybdenum.com)
(TXT) w3m dump (blog.polybdenum.com)
| iamgopal wrote:
| Security was the prime reason app engine couldn't add features
| fast enough, and hence couldn't gain the market fast enough, else
| it could have been the money maker for google.
| frew wrote:
| This is impressive! For folks who are worried about what this
| says about App Engine's security - historically the JVM level
| sandboxing was one part of an overall sandboxing story (not
| surprisingly, very similar to Chrome's setup) and my
| understanding, although haven't been on the team for a decade at
| this point, is that the JVM-level restrictions have been
| effectively replaced by a gVisor-based solution.
| twistedpair wrote:
| Note that GAE has two flavors: - Standard (constrained, more
| shared bits) - Flex (supply your own container, get your own
| instance)
| kasperni wrote:
| In-process sandboxing is falling out of favour.
|
| Code Access Security has been removed from the .NET framework
| [1]. And Java's SecurityManager is deprecated for removal in
| future versions of Java [2].
|
| [1] https://docs.microsoft.com/en-
| us/dotnet/framework/misc/code-...
|
| [2] https://openjdk.java.net/jeps/411
| pjmlp wrote:
| Yeah, the way we adopted threading and dynamic libraries for
| plugins is on the way out and we are back into multiple process
| with IPC, for more stability and security.
|
| The downside is they are more memory hungry.
| CodesInChaos wrote:
| > In-process sandboxing is falling out of favour.
|
| Javascript and webassembly still aim for for in process
| sandboxing, though browsers add process level security as
| defense-in-depth.
| pron wrote:
| They do not, at least not in the way "in-process sandboxing"
| means in the context of Java's Security Manager, which is now
| being considered for deprecation and removal. Java's Security
| Manager does not create a single set of permissions for the
| entire Java program, but rather assigns different permissions
| to different Java classes running in the same program and
| even on the same thread, through a mechanism that assigns
| different permissions to different subroutines on the call-
| stack, composing them in some elaborate way. The same
| operation can be allowed or blocked depending on the call-
| stack by which it is reached. For example, writing to a
| specific file or socket could be allowed if the call stack
| contains a trusted subroutine that is known to ensure the
| access is done "safely" but blocked otherwise.
|
| The reason this is now being considered for removal is that
| even though this mechanism is very flexible and powerful in
| theory, it is too elaborate to be used correctly by most
| programmers in practice.
| nahuel0x wrote:
| There is a replacement in sight?
| pron wrote:
| No, because Java's security hasn't been based on the
| Security Manager sandbox for years, and very few people
| use it (and almost no one uses it for sandboxing
| untrusted code -- what it was designed to do). There will
| be replacements, and in some cases there are already, for
| other (ab)uses of the Security Manager, such as tracking
| I/O events.
| londons_explore wrote:
| That actually sounds awesome... A bit like the setuid bit
| on unix for running the ping utility always as root (normal
| users can't receive ping packets), but with a whole lot
| more flexibility.
|
| I can see how careless use of it can lead to an
| unintentionally rather massive security surface area
| though...
| nyanpasu64 wrote:
| Would capability-based security be more effective than what Java
| attempted for in-process isolation?
| flakiness wrote:
| I think GAE isolation nowadays is done by gVisor[1]? Looking at
| the doc [2] however, it seems like the old "proprietary"
| mechanism is still used for old (first generation) runtime.
| Probably this post is about that version. [1]
| https://cloud.google.com/blog/products/containers-kubernetes/how-
| gvisor-protects-google-cloud-services-from-cve-2020-14386
| [2] https://cloud.google.com/appengine/docs/standard/runtimes
| prattmic wrote:
| Even the first-generation runtimes no longer use this
| mechanism. Note https://cloud.google.com/appengine/docs/standar
| d/java/migrat...: "All standard Java classes are now available,
| and there is no class allowlist."
| flakiness wrote:
| That's good to know!
| eternalban wrote:
| This is a beautiful, impressive, hack. The blog post itself is a
| minor tour de force.
| exabrial wrote:
| In process sandboxing was definitely one of the worst ideas
| attempted in the early days of Java. None of my jobs in the last
| 10 years have ran with the security manager enabled, as it's just
| useless. I'm suspicious of any modern technology attempting to do
| the same thing, as it's just hard to get right.
|
| When IBM developed Websphere for the 1996 Atlanta Olympics, they
| wanted a mainframe, but you know, web stuff. The model was doomed
| from the start, as they designed the JVM to run as a process.
|
| Sun attempted tried to get deeper kernel support for the JVM with
| Solaris, but ultimately just ended up developing the precursor to
| LXC Containers called Solaris Zones.
|
| What we have today with containers is pretty awesome but it was
| definitely a bumpy road to figure it all out.
| momothereal wrote:
| What's the link between WebSphere and the Olympic games?
| jfrunyon wrote:
| > In process sandboxing was definitely one of the worst ideas
| attempted in the early days of Java. None of my jobs in the
| last 10 years have ran with the security manager enabled, as
| it's just useless. I'm suspicious of any modern technology
| attempting to do the same thing, as it's just hard to get
| right.
|
| I think Android has done a very good job with their
| permissions, which seem quite similar to me. Am I missing
| something?
|
| Yes, properly limiting permissions is difficult, and there can
| be bugs, but that's true regardless of what layer the security
| controls are applied at.
| gene91 wrote:
| The comment from @pron in the sibling thread explains the
| difference. Android applications, in general, don't share
| process.
| pjmlp wrote:
| .NET Core doesn't support the .NET version of security manager
| (CAS), and the is actually a JEP for deprecating the security
| manager for removal.
|
| The JAAS idea was quite good, however it was too complex for
| most developers to implement properly.
|
| I see a big failure for .NET and Java not having been a JIT/AOT
| stack since the beginning, and now we are going through their
| reboots while trying to keep the existing ecosystems to fall
| apart in the process.
| _old_dude_ wrote:
| I believe it's JEP 411 [1], good ridance, there is nothing
| worst than a false sense of security.
|
| [1] https://openjdk.java.net/jeps/411
| taklamunda wrote:
| I also wanna learn the technical, plz share with me
| scottlu2 wrote:
| +1 impressive independent of anything else. +1 for doing this as
| an intern.
___________________________________________________________________
(page generated 2021-05-06 23:01 UTC)