Re: Survey of lua sandboxes?

[HyperHacker <hyperhacker@...>]

On Tue, Dec 27, 2011 at 14:14, Sam Roberts <vieuxtech@gmail.com> wrote:
> On Mon, Dec 26, 2011 at 3:11 PM, David Favro <lua@meta-dynamic.com> wrote:
>> On 12/26/2011 03:31 PM, Gé Weijers wrote:
>>> What comes to mind in sandboxing Lua:
>>>   * disable the code path that loads compiled VM code altogether, in the Lua
>>>     C source. The small CPU time savings are not worth the risk when you're
>>>     about to run potentially malicious code.
> ...
>> Likewise for the first point, providing that you're willing to also disallow
>> loading of uncompiled source code, which might often be the case in
>> sandboxed contexts.
>
> Perhaps you are not aware that maliciously constructed compiled code
> can be used to segfault the interpreter, so a careful attacker could
> probably execute arbitrary code. See conversations in the archive.
>
> How careful your sandbox has to be depends on the threat model, how
> important what you
> are trying to protect is, and whether you are protecting from active
> malicious attackers,
> or just inadvertent misuse.
>
> Cheers,
> Sam
>

Segfaults are the least of your worries; it's been demonstrated that
crafted bytecode can (at least in 5.1) be an exploit vector for
execution of arbitrary native machine code. Ways to protect against
that are A) disallow loading of bytecode, B) try to verify all
bytecode, or C) let the code do anything it wants, but in a highly
restricted environment. A is the most common method; B has been
attempted, but is very difficult to get right.

There are a few sites out there that let you paste in and execute
arbitrary code in languages such as C. These run the program (and even
the compiler) in a heavily sandboxed environment, such that there's
nothing a program *can* do to cause any real damage. I don't recall
any names off hand, unfortunately.

-- 
Sent from my toaster.