Re: Bytecode: Safe or not? / luac manual

[David Given <dg@...>]

On 01/11/11 20:09, Sean Conner wrote:
[...]
>   I don't know, doing a search for "java bytecode verifier vulnerability"
> certain brought up a ton of results.  Granted, the results appear to be
> several years old, but from a quick scan through the results, it appears
> that Java bytecode verification wasn't quite as trivial as you make it
> sound.

To my mind, bytecode verification is like an antibiotic: complicated,
fragile, full of nasty exploitable corner cases, and something you only
use if you really have to.

If you really want to kill germs, use bleach. Brute force, dead simple,
incredibly hard to avoid, and cheap.

Instead of doing bytecode verification, create a new process, put a Lua
VM in it with some memory, take all its system calls away, and give it
exactly two ways of interacting with the outside world: send message to
channel and receive message from channel. Now it doesn't *matter* if you
run untrusted machine code. The worst thing it could do is to send
malicious packets down your channels, and it's easy to harden those. And
now it's trivial to nuke the entire process, cleanly, reliably, and
leaving no detritus on the system.

(Google's NaCl is doing something similar, although they're also doing
some bytecode (well, machine code) verification as well.)

In fact, mobile agents are a very old idea. What they're for is to allow
the code to migrate across the network to a point close to where their
data is. For example: a complex database query that automatically moves
off your workstation and onto the database server itself.

Another good use case are user interfaces. You want the interactive bits
of the application to be close to the user to make it responsive -- the
View and Controller in the old MVC terminology. Anyone who's tried to
run an X program across a slow network link knows about this.

(In fact, Sun had a good attempt at this sort of thing with their NeWS
technology: terminals which ran an object-oriented Postscript dialect.
Applications would write their user interface in Postscript and upload
it over the network link, so it ran locally on the terminal, and then
communicated with it via RPC. It worked startlingly well. Alas, it got
licensed to death. If they'd opened the technology, it'd have taken over
the world. As it was, the MIT licensed X beat it into the ground.)

I think that the main reason people don't do this sort of thing any more
is that the Internet these days is so much simpler than it was in the
old days --- topologically, that is --- that every server is reachable
from every other server, so automatic migration just isn't needed. And
the remaining needs are filled by simpler, cruder alternatives. e.g. SQL
for the database example, Javascript and HTML for the user interface
example. They're both pretty dire, but they both *work*.

But I definitely think there's a role for agents in user interfaces.
Right now web apps are *sort of* mobile, but only because the user
interface itself is stateless --- they don't migrate, you just restart
the user interface on another machine and because all the state's on the
server it's identical to your old machine. This sucks. It leads to lousy
apps which are hard to write (because of the terrible RPC mechanisms in
HTML5).

If you could come up with a proper agented user interface which *would*
migrate from device to device, that would be awesome. It would be even
more awesome if you could make it secure *from the remote server's point
of view* --- one of the huge problems with web apps is that they can't
trust the code running on the user's browser, which makes RPC *even
more* cumbersome. I don't know if this is even possible. It'd involve
some very cunning crypto.

But I would really like to be able to chuck a Thunderbird session from
my laptop to my desktop, half-written emails and all, and then chuck it
back again when I needed to go out...

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "Under communism, man exploits man. Under capitalism, it's just the
│ opposite." --- John Kenneth Galbrith

Attachment: signature.asc
Description: OpenPGP digital signature