Trusted Language Requirements
Trusted Language Requirements
Posted Apr 29, 2015 3:14 UTC (Wed) by gmatht (subscriber, #58961)In reply to: Unsafe Blocks by Cyberax
Parent article: Rust Once, Run Everywhere
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).