Lua Sandbox Security Research

A skill for security researchers and developers to analyze, test, and harden Lua sandbox environments in embedded applications, game clients, and scripting engines.

When to Use This Skill

Use this skill when:

• You need to enumerate a Lua sandbox environment for security testing
• You're assessing Lua VM security in game clients or embedded applications
• You want to identify dangerous primitives exposed in a Lua environment
• You're testing for sandbox escape vulnerabilities
• You need to harden a Lua environment against exploitation
• You're reviewing Lua security configurations or bytecode loading policies

Core Concepts

The Lua Sandbox Model

Lua sandboxes typically restrict access to standard libraries (io, os, package, debug) while exposing a limited set of safe functions. However, misconfigurations often leave dangerous primitives reachable, enabling:

• Command execution via

  io.popen()

  or

  os.execute()

• Arbitrary code execution via

  load()

  ,

  loadstring()

  ,

  loadfile()

• Native library loading via

  package.loadlib()

• Memory corruption via bytecode exploitation (Lua ≤5.1)

Attack Surface

The global environment

_G

• io/os: Direct command execution
• load/loadstring/loadfile: Source/bytecode execution
• package: Dynamic library loading
• debug: Privilege escalation within VM
• LuaJIT ffi: Native code calls

Enumeration Techniques

Dump the Global Environment

Start by inventorying all reachable globals. Use any available output primitive:

-- Basic _G dumper
local function dump_globals(out)
  out("=== DUMPING _G ===")
  for k, v in pairs(_G) do
    out(tostring(k) .. " = " .. tostring(v))
  end
end

Alternative Output Channels

When

print()

-- Example: Using game UI as output
local function create_output_channel()
  -- Some engines require initialization
  H.PlaySound(0, "r[1]")
  return function(msg)
    H.Say(1, msg)
  end
end

-- Usage
local out = create_output_channel()
dump_globals(out)

Generalize this pattern: Any textbox, toast, logger, or UI callback accepting strings can act as stdout for reconnaissance.

Auto-Run Callbacks

If the host pushes scripts to clients with auto-run hooks, payloads execute on load:

function OnInit()
  -- Payload executes when script loads
  io.popen("whoami")
end

-- Other common callbacks: OnLoad, OnEnter, OnStart

Dangerous Primitives Checklist

During enumeration, specifically hunt for:

io.popen

io.popen("id")

os.execute

os.execute("/bin/id")

load/loadstring

load("os.execute('id')")()

loadfile/dofile

dofile("/tmp/payload.lua")

package.loadlib

package.loadlib("./lib.so", "luaopen_foo")

debug

debug.getinfo

debug.sethook

ffi

ffi.C.system("id")

Testing Primitive Availability

-- Check if io.popen is reachable
if io and io.popen then
  local handle = io.popen("echo test")
  local result = handle:read("*a")
  handle:close()
  print("io.popen works: " .. result)
end

-- Check loadstring
if loadstring then
  local f = loadstring("return 42")
  print("loadstring works: " .. f())
end

-- Check package.loadlib
if package and package.loadlib then
  print("package.loadlib is exposed")
end

Bytecode Exploitation (Advanced)

When

load/loadstring

io/os

Key Facts

• Lua ≤5.1: Bytecode verifier has known bypasses
• Lua 5.2+: Verifier removed (applications should reject precompiled chunks)
• Attack flow: Leak pointers → craft type confusion → arbitrary read/write → code execution

Basic Bytecode Loading

-- Create and load bytecode
local function create_bytecode()
  local bc = string.dump(function() return 0x1337 end)
  local f = loadstring(bc)
  return f()
end

print(create_bytecode()) -- 4919

Note: Bytecode exploitation is engine/version-specific and requires reverse engineering. See references for detailed primitives.

Hardening Recommendations

Server-Side Controls

1. Reject or rewrite user scripts - Don't execute untrusted code directly
2. Allowlist safe APIs - Only expose necessary functions
3. Strip dangerous globals:

   _ENV = {}
   _ENV.print = print  -- Only safe functions
   -- Remove: io, os, load, loadstring, loadfile, dofile
   -- Remove: package.loadlib, debug, ffi
   

Client-Side Controls

1. Minimal _ENV - Start with empty environment, add only what's needed
2. Forbid bytecode loading - Reject

   loadstring

   with precompiled chunks
3. Reintroduce bytecode verifier - Or implement signature checks
4. Block process creation - Prevent child process spawning from client

Telemetry & Detection

• Alert on gameclient → child process creation after script load
• Correlate UI/chat/script events with process spawning
• Monitor for unusual

  io.popen

  or

  os.execute

  calls

Security Assessment Workflow

1. Enumerate - Dump

   _G

   and identify reachable primitives
2. Test - Verify dangerous functions actually work
3. Exploit - If primitives are exposed, demonstrate impact
4. Report - Document findings with reproduction steps
5. Remediate - Apply hardening recommendations

References

• This House is Haunted: AION housing Lua VM RCE
• Bytecode Breakdown: Factorio Lua Security Flaws
• Lua 5.1 bytecode verifier discussion
• Exploiting Lua 5.1 bytecode

Important Notes

• Authorization: Only test Lua sandboxes you own or have explicit permission to assess
• Scope: Document what you're testing and get written authorization
• Safety: Some exploitation techniques can crash applications or corrupt data
• Defense: This skill is equally valuable for hardening Lua environments against attacks