Exploiting Lua 5.1 on 32-bit Windows

One obvious way to patch is to validate types in OP_FORLOOP, just as in OP_FORPREP.

My guess is that it won't be patched. The general consensus is that untrusted bytecode is inherently unsafe[1]. Use the source everwhere, which is safe and also portable. If you're using bytecode for performance or security reasons, you're illusioned, stop.

Background: Lua 5.1 has a bytecode verifier, which was designed to reject malformed (and potentially harmful) bytecode. However the author of this exploit (Peter Cawley) has found way after way to get harmful bytecode past the verifier over the past few years.

Ultimately in Lua 5.2 the verifier was removed to avoid giving a false sense of security to developers. Ironically Peter Cawley stated that would have preferred to keep the verifier and just fix the holes[2]. He has written an external verifier for 5.2[3].

My advice is, again, don't load untrusted bytecode. This also means that wherever you execute untrusted source, you must check that the first byte is not 0x1B ("\27") before passing it to loadstring() (or use the 'mode' parameter to load() in 5.2).

[1]: http://www.lua.org/bugs.html#5.1.4-1

[2]: http://lua-users.org/lists/lua-l/2011-03/msg01123.html

[3]: https://code.google.com/p/lbcv/

This exploit works because the sandbox designer failed to forbid bytecode loading, which is known to be much more unsafe than accepting only source files. I believe there are several known ways to crash a VM by loading bad bytecode, for instance.

Patch loadbuffer() et al. to make it refuse bytecode files and you're safe.