3 ms·

Exploiting Lua 5.1 on 32-bit Windows

39 points by tiagobraw 13y ago

oakwhiz 13y ago
Excellent and very detailed explanation of the exploit. I wish more exploits were documented like this.
otikik 13y ago
This comes with an excellent timing, since I have been doing Lua sandboxing stuff myself. I will have to study this on detail, but it seems there is little I can do on this one, besides waiting for Lua to be patched somehow. By the way, the only thing I miss is instructions on how to patch Lua so this is not a vulnerability any more, if that's possible at all. Good find, and thanks!
- sanxiyn 13y ago
  One obvious way to patch is to validate types in OP_FORLOOP, just as in OP_FORPREP.
- MattJ100 13y ago
  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 http://www.lua.org/bugs.html#5.1.4-1 [2]: http://lua-users.org/lists/lua-l/2011-03/msg01123.html http://lua-users.org/lists/lua-l/2011-03/msg01123.html [3]: https://code.google.com/p/lbcv/ https://code.google.com/p/lbcv/
- fab13n 13y ago
  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.

39 points by tiagobraw 13y ago

Excellent and very detailed explanation of the exploit. I wish more exploits were documented like this.

This comes with an excellent timing, since I have been doing Lua sandboxing stuff myself. I will have to study this on detail, but it seems there is little I can do on this one, besides waiting for Lua to be patched somehow. By the way, the only thing I miss is instructions on how to patch Lua so this is not a vulnerability any more, if that's possible at all. Good find, and thanks!

sanxiyn 13y ago
One obvious way to patch is to validate types in OP_FORLOOP, just as in OP_FORPREP.
MattJ100 13y ago
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 http://www.lua.org/bugs.html#5.1.4-1 [2]: http://lua-users.org/lists/lua-l/2011-03/msg01123.html http://lua-users.org/lists/lua-l/2011-03/msg01123.html [3]: https://code.google.com/p/lbcv/ https://code.google.com/p/lbcv/
fab13n 13y ago
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.