lua-users wiki: Sand Boxes (original) (raw)

This page uses setfenv in its examples, setfenv is no longer available as of Lua 5.2, so it needs an update. If you use Lua 5.2 do not use this code, I would have updated this myself, but I have no experience in sandboxing.

This page discusses issues relating to sandboxing: running untrusted Lua code in a restricted Lua environment.

WARNING!!!

Sandboxing is tricky and generally speaking difficult to get right [3]. You should start by trusting nothing and only permit things that you are absolutely sure are safe (i.e. whitelist rather than blacklist approach). It's difficult to be sure some code is safe without thorough knowledge of the language and implementation (e.g. hash table performance may have poor performance in rare cases [4]). It's also possible there could be a bug in the Lua implementation (see [bugs]), so you should monitor bug reports on the mailing list and possibly take additional steps for isolation in the event of such a breach, such as operating system level isolation mechanisms (like restricted user accounts or a [chroot jail]). You should also keep your operating system patched and secured by means like firewalls. Operating system level resource limits may also be necessary [5]. Restricting to a subset of the Lua language can mitigate some of these concerns.

See some libs in "Sandboxing" chapter of LibrariesAndBindings.

The following notes are probably incomplete and intended only as a starting point.

A Simple Sandbox

The following is one of the simplest sandboxes. It is also one of the most restrictive, except it doesn't handle resource exhaustion issues.

local env = {}

local function run(untrusted_code) if untrusted_code:byte(1) == 27 then return nil, "binary bytecode prohibited" end local untrusted_function, message = loadstring(untrusted_code) if not untrusted_function then return nil, message end setfenv(untrusted_function, env) return pcall(untrusted_function) end

local function run(untrusted_code) local untrusted_function, message = load(untrusted_code, nil, 't', env) if not untrusted_function then return nil, message end return pcall(untrusted_function) end

assert(not run [[print(debug.getinfo(1))]]) assert(run [[x=1]]) assert(run [[while 1 do end]])

Code in this sandbox can create variables in the sandbox environment, create values of primitive types (thereby allocating memory), and perform computations. There is no limit to memory usage and computation, so the untrusted code could still severely impact system performance unless further restrictions are made. The sandbox does not have access to I/O nor functions and variables outside its environment. The only way for the sandbox to communicate with the external world is by affecting its environment (e.g. getting and setting variables and calling functions in that environment), assuming there is code outside the sandbox that also has access to those variables and functions.

You could write a parser that accepts a subset of the Lua language (e.g. prevents loops), but this will likely still be insufficient to fully prevent CPU exhaustion.

Table of Variables

The following is a list of Lua 5.1 variables with descriptions of how safe they for use in sandbox environments. Note that whether a variable is safe or not may **depend on the security requirements of your particular application** and your Lua state. No warranty is given that the following listing is complete or correct, but it is only a guideline. To make a sandbox you should start with an empty environment and pull in only functions you know for certain to be safe [1] (i.e. a whitelist not a blacklist). You should not rely on the manual providing a complete list of functions (e.g. HiddenFeatures).

NOTE: The following list has not been updated for Lua 5.2.

• assert - SAFE
• collectgarbage - UNSAFE - can globally and adversely affect garbage collection
• dofile - UNSAFE - The may read arbitrary files on the file system. It can also read standard input. The code is run under the global environment, not the sandbox, so this can be used to break out of the sandbox. Related discussion: DofileNamespaceProposal. Also unsafe if file is compiled bytecodes (see load).
• error - SAFE
• _G - UNSAFE - by default this contains the global environment. You may, however, want to set this variable to contain the environment of the sandbox.
• getfenv - UNSAFE - this can locate an environment outside of the sandbox, thereby breaking out of the sandbox. LuaList:2007-11/msg00202.html
• getmetatable - UNSAFE - Note that getmetatable"" returns the metatable of strings. Modification of the contents of that metatable can break code outside the sandbox that relies on this string behavior. Similar cases may exist unless objects are protected appropriately via __metatable. Ideally __metatable should be immutable.
• ipairs -- SAFE
• load - UNSAFE. The function returned has the global environment, thereby breaking out of the sandbox. More seriously, is dangerous if loading bytecode rather than Lua source: LuaList:2010-08/msg00487.html .
• loadfile - UNSAFE. See load and dofile
• loadstring -- UNSAFE. See load. Even this:

local oldloadstring = loadstring local function safeloadstring(s, chunkname) local f, message = oldloadstring(s, chunkname) if not f then return f, message end setfenv(f, getfenv(2)) return f end

isn't safe. For example, pcall(safeloadstring, some_script) will load some_script in global environment. --SergeyRozhenko

• next - SAFE
• pairs - SAFE
• pcall - SAFE
• print - SAFE (assuming output to stdout is ok)
• rawequal - UNSAFE (potentially?) - bypasses metatables
• rawget - UNSAFE - bypasses metatables
• rawset - UNSAFE - bypasses metatables
• select - SAFE
• setfenv - UNSAFE - can modify environments of functions that are up the call-chain and outside the sandbox
• setmetatable - UNSAFE - see getmetatable
• tonumber - SAFE
• tostring - SAFE
• type - SAFE
• unpack - SAFE
• _VERSION - SAFE
• xpcall - SAFE
• coroutine - UNSAFE - modifying this table could affect code outside the sandbox
• coroutine.create - SAFE
• coroutine.resume - SAFE
• coroutine.running - SAFE
• coroutine.status - SAFE
• coroutine.wrap - SAFE
• coroutine.yield - SAFE (probably) - assuming caller handles this
• module - UNSAFE - for example, modifies globals (e..g package.loaded) and provides access to environments outside the sandbox.
• require - UNSAFE - modifies globals (e.g. package.loaded), provides access to environments outside the sandbox, and accesses the file system.
• package - UNSAFE - modifying this table could affect code outside the sandbox
• package.* - UNSAFE - affects module loading outside the sandbox
• package.loaded - UNSAFE - provides access to modules loaded outside the sandbox
• package.loaders - UNSAFE - provides access to loading modules outside the sandbox
• package.loadlib - UNSAFE - loads arbitrary executable code that runs outside of Lua
• package.path/package.cpath - UNSAFE (effectively) since this is probably useful only for UNSAFE functions. In itself, it is probably SAFE, for reading that is.
• package.preload - UNSAFE (probably) - may allow loading modules outside the sandbox
• package.seeall - UNSAFE - provides access to the global environment
• string - UNSAFE - modifying this table could affect code outside the sandbox
• string.byte - SAFE
• string.char - SAFE
• string.dump - UNSAFE (potentially) - allows seeing implementation of functions.
• string.find - SAFE -- warning: a number of functions like this can still lock up the CPU [6]
• string.format - SAFE
• string.gmatch - SAFE
• string.gsub - SAFE
• string.len - SAFE
• string.lower - SAFE
• string.match - SAFE
• string.rep - SAFE
• string.reverse - SAFE
• string.sub - SAFE
• string.upper - SAFE
• table - UNSAFE - modifying this table could affect code outside the sandbox
• table.insert - SAFE
• table.maxn - SAFE
• table.remove - SAFE
• table.sort - SAFE
• math - UNSAFE - modifying this table could affect code outside the sandbox
• math.abs - SAFE
• math.acos - SAFE
• math.asin - SAFE
• math.atan - SAFE
• math.atan2 - SAFE
• math.ceil - SAFE
• math.cos - SAFE
• math.cosh - SAFE
• math.deg - SAFE
• math.exp - SAFE
• math.floor - SAFE
• math.fmod - SAFE
• math.frexp - SAFE
• math.huge - SAFE
• math.ldexp - SAFE
• math.log - SAFE
• math.log10 - SAFE
• math.max - SAFE
• math.min - SAFE
• math.modf - SAFE
• math.pi - SAFE
• math.pow - SAFE
• math.rad - SAFE
• math.random - SAFE (mostly) - but note that returned numbers are pseudorandom, and calls to this function affect subsequent calls. This may have statistical implications.
• math.randomseed - UNSAFE (maybe) - see math.random
• math.sin - SAFE
• math.sinh - SAFE
• math.sqrt - SAFE
• math.tan - SAFE
• math.tanh - SAFE
• io - UNSAFE - modifying this table could affect code outside the sandbox
• io.* - These can be UNSAFE as they provide access to the file system. Note also that io.close on standard file handles (e.g. io.stdin) may be unsafe and could cause a crash.
• io.read - SAFE (probably)
• io.write - SAFE (probably) - note: potentially could consume all disk space, thereby bringing down a system
• io.flush - SAFE (probably)
• io.type - SAFE
• os - UNSAFE - modifying this table could affect code outside the sandbox
• os.clock - SAFE
• os.date - UNSAFE - This can crash on some platforms (undocumented). For example, os.date'%v'. It is reported that this will be fixed in 5.2 or 5.1.3.
• os.difftime - SAFE
• os.execute - UNSAFE - calls external programs
• os.exit - UNSAFE - terminates program
• os.getenv - UNSAFE (potentially) - depending on what environment variables contain
• os.remove - UNSAFE - modifies file system
• os.rename - UNSAFE - modifies file system
• os.setlocale - UNSAFE - modifies global locale, affecting code outside the sandbox
• os.time - SAFE
• os.tmpname - UNSAFE (maybe) - only in that it provides some information on the structure of the file system
• debug - UNSAFE - modifying this table could affect code outside the sandbox
• debug.* - UNSAFE - functions here can break out of the sandbox and access variables outside the sandbox. Note warnings in the Lua Reference Manual concerning debug.
• newproxy - UNSAFE (potentially) - This is an undocumented function (HiddenFeatures), so it does not have a specified interface that you can rely on. newproxy(nil) and newproxy(true) are probably safe, though fairly useless if getmetatable is disabled, at least for the proxy. newproxy(o) where o is another proxy object will assign the metatable of o to the new proxy, so there are potential side-effects on o or the metatable of o for any exposed proxy o.

--DavidManura

Older Comments

Anonymous: Attacks to consider:

• io functions, you will have to remove/hide/wrap them, of course
• when hiding the env, make sure the untrusted code can't getenv(some_lib_function) to get it back
• dofile('/home/username/.some_other_app/passwords') can read a totally unrelated Lua config file
• loading unrelated C libraries from other projects
• Lua 5.0: maybe the user can add a metatable a string object, which affects all string concatenations, tricking a library function into manipulating the wrong files (Lua 5.1 requires C the API to do this)
• ??? maybe the stacktrace can be expected to get back the env ???
• Running an infinite loop. (Bad, but not really harmful.)
• Using up all available memory.
• Check critical function arguments (stuff with metamethods attached where string/int expected)
• The usual C stuff (buffer overflow, integer overflow) just requires careful coding
• __gc on userdata metatables
• Currently the quota enforcer does not protect agains malicious scripts using pcall (and xpcall) UNSAFE? [details]

See Also

• The lua-l archive [2] contains discussions on sandboxing.

RecentChanges · preferences
edit · history
Last edited December 12, 2023 12:04 pm GMT (diff)