Re: Bytecode: Safe or not? / luac manual

[Josh Simmons <simmons.44@...>]

On Wed, Nov 2, 2011 at 8:51 AM, David Given <dg@cowlark.com> wrote:
> 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
>
>

What problems does migrating the entire application solve that a
distributed messaging architecture does not?