Re: Making LUA safe to execute untrusted scripts

[Luiz Henrique de Figueiredo <lhf@...>]

Here are some comments on this very interesting thread.
It's a bit long, so bear with me :-)

>From: "Luc Van den Borre" <luc@nuclide.com>

>I'm interested in mobile code - (LUA) code received by an application from an external, perhaps untrusted source.

The current version (3.2) of luac has a '-t' option. To quote the man page
(http://www.tecgraf.puc-rio.br/lua/manual/luac.html):

-t   perform a thourough integrity test when undumping. Code that passes
     this test is completely safe, in the sense that it will not break the
     interpreter. However, there is no guarantee that such code does
     anything sensible. (None can be given, because the halting problem is
     unsolvable.)

The function that implements this test in luac is

	void luaU_testchunk(TProtoFunc* Main);

declared in luac.h. So, it is already a public function and could be used by
a host program.
When luaU_testchunk finds something wrong with the code, it calls lua_error,
and so errors can be trapped.
But perhaps it would be easier to have an API that receives a lua_Object
or a chunk of memory containing bytecodes that returns yes or no.
I could do this if there is demand.

>- restrictions on file-access

It is easy to undefine any built-in function before running a chunk.
CGILua does exactly this.

>- cpu usage limitations (which would probably mean pre-emptive multitasking between scripts)
>- memory limitations (no more than a fixed amount of memory to play with)
>- time limitations (run no longer than fixed amount of cycles or get killed)

This is not so simple to define in detail.
But you could do something with the call hook or by counting the number of
Lua VM instructions that are executed (you'd have to change luaV_execute a
little to do this).

The new version, which has now been officiallu named 4.0 (alpha), will have
states with user-selected stack size.

>- doesn't crash - or at least crashes nicely without taking down the host program

This is a *design* requirement for Lua.
Lua programs should never crash the host.

>From: Bennett Todd <bet@rahul.net>

>Noble goals, and nicely specified. A couple more to add:
>
>  - restrictions on memory access within the program (can't read or
>    write arbitrary locations in memory within the process)

This is also by design.
Not even the presence of userdata threatens the integrity of the host's memory.

>I've no idea whether Lua is well-suited to applying such
>restrictions, but I'll say this: if its designers felt that it was,
>I'd be a _lot_ liklier to trust it in a role like this than any
>competitor I've seen, including most especially Java and Javascript.

We do feel that Lua provides a trusted enviroment for running scripts.
We take great care that the implementation does this.

>So far that collection of simplicity hasn't been assembled. But
>then, there hasn't been a programming language architect in decades
>who delivered simplicity like Lua's simplicity. And Lua's a _lot_
>prettier than Forth:-).

Thanks for the compliments. They show that we have succeeded!
Of course, every programming language has is quirks, and we cannot please
everyone. But Lua *is* great, even if I say so myself! :-)

>From: "Luc Van den Borre" <luc@nuclide.com>

| >   - restrictions on memory access within the program (can't read or
| >     write arbitrary locations in memory within the process)
| Lua already does this, right?
>Yes, but (how easily) can a malicious hacker find ways around this?

Like I said above, we don't know of any exploits that a malicious hacker could
use to crash a host program from within Lua. Any such exploit is definitely a
bug and will be fixed promptly.

>From: "Nick Trout" <nick@videosystem.co.uk>

>It would be really nice if there was a version of Lua that you could just give
>some memory (including the state info) and all allocation was done through this
>and all code was generated in this.

This seems easy to do because it only requires to change luaM_realloc, as
someone already remarked.

--lhf