[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Survey of lua sandboxes?
- From: David Favro <lua@...>
- Date: Fri, 30 Dec 2011 13:13:04 -0500
On 12/27/2011 04:14 PM, Sam Roberts wrote:
> On Mon, Dec 26, 2011 at 3:11 PM, David Favro <email@example.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.
I am indeed aware; when I said "disallow loading of uncompiled source code"
I meant to ask the question, how would malicious bytecode be loaded if we
prepare an environment which does not contain references to dofile(),
load(), loadfile(), loadstring(), debug library, etc. -- but I suppose that
the answer would be that the untrusted script that the original poster
described could itself be malicious bytecode rather than script.
Nonetheless, if the threat model is only "inadvertent misuse" than I think
that one might accept this vulnerability in exchange for the advantage of a
vanilla runtime. It's a pity there's no way to easily distinguish between
bytecode and source code (or specify which is acceptable) in lua_load()
and/or load() in the vanilla API.
Anyhow, my main point was regarding Gé's second point, the comment about
removing references to undesirable API entry-points by modifying the runtime
rather than using environments; so my point remains, provided one has solved
his first [load bytecode] and third [runaway resource use] points, is there
any known vulnerability by which one can access "privileged" API routines
when executing script in an environment which does not contain references?