Unsafe Blocks [LWN.net]

Unsafe Blocks

Posted Apr 28, 2015 12:56 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
In reply to: Unsafe Blocks by epa
Parent article: Rust Once, Run Everywhere

> I thought it went okay?
Nope. There's an unending litany of bugs, mostly caused by some clueless developers leaving around publicly accessible (or ones that can be accessed with some care) privileged classes with functionality amounting to "sudo bash".

For example:
http://schierlm.users.sourceforge.net/TypeConfusion.html
http://krebsonsecurity.com/2015/01/java-patch-plugs-19-se...
...

> There were Java sandbox bugs but the record is surely better than Javascript, and a long way ahead of anything that doesn't use language isolation (ActiveX).
ActiveX has _no_ protection at all, so it's not a comparison at all. And JavaScript is generally more secure, because normally it has very few external access points.

to post comments

Trusted Language Requirements

Posted Apr 29, 2015 3:14 UTC (Wed) by gmatht (subscriber, #58961) [Link] (2 responses)

There's an unending litany of bugs, mostly caused by some clueless developers leaving around publicly accessible (or ones that can be accessed with some care) privileged classes with functionality amounting to "sudo bash"

Agreed. For example, one bug was caused by starting a JMX server. That vulnerability was the first time I had heard of JMX servers. To secure a language (or anything else) you need to minimise the attack surface. The bytecode verifier used by Java seems basically OK now, but with Java the attack surface seems to be pretty much everything.

Avoiding ambient authority can reduce the attack surface. For example consider the following function prototype:

Bitmap image_decoder(const Bytes b);

Clearly image_decoder needs two special privileges: to read from b, and to return a Bitmap. The compiler obviously knows this, and can grant those privileges automatically. If we limited the ambient authority granted to all code to a few well thought out and important rights (say allocating memory [how much?] and writing to the log), then writing a malicious image_decoder would become a lot harder. If the image_decoder really needed to run start JMX servers we could alter the prototype to something like:

Bitmap image_decoder(const Bytes b, JMXFactory f);

Now the image_decoder could use the flaw in the JMXFactory to break out of its sandbox. But once the JMXFactory is fixed, the author couldn't just switch to using a flaw in the CORBA implementation (or whatever the whack-a-mole vulnerability of the day happens to be).

Trusted Language Requirements

Posted Apr 29, 2015 9:59 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

> Clearly image_decoder needs two special privileges: to read from b, and to return a Bitmap. The compiler obviously knows this, and can grant those privileges automatically. If we limited the ambient authority granted to all code to a few well thought out and important rights (say allocating memory [how much?] and writing to the log), then writing a malicious image_decoder would become a lot harder.
That's exactly what modern languages with effect typing systems do, see for instance Idris or DDC (disciple). Not the first time that functional languages show how it's done.

Trusted Language Requirements

Posted May 2, 2015 9:21 UTC (Sat) by roc (subscriber, #30627) [Link]

Until someone writes a big, complicated system in that sort of language, nothing really has been shown. It's easy to design a sophisticated type system that can prove amazing things about toy programs.

Unsafe Blocks

Posted Apr 30, 2015 10:16 UTC (Thu) by epa (subscriber, #39769) [Link]

Ah, you are referring to exploits using parts of the Java standard library which wrap unsafe code or buggy type casts. I agree, there is a lot of garbage in there. I would have expected applets or other sandboxed code to be restricted to a safe subset of the library, but apparently not.

I was thinking of Java the language, where admittedly there have been several bytecode verification bugs, but the core sandboxing model seems reasonably sound.

Of course, though, security depends not just on the theoretical model but on the quality of implementation all the way through the stack, and there Java falls short.