[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Bytecode: Safe or not? / luac manual
- From: Josh Simmons <simmons.44@...>
- Date: Fri, 4 Nov 2011 12:02:28 +1100
On Wed, Nov 2, 2011 at 8:51 AM, David Given <firstname.lastname@example.org> 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
> 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
> 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
> 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?