Redis 2.8.21 and 3.0.2 are out fixing the issue. The patch was provided by Ben Murphy directly (the same researcher uncovering the issue). So two times thanks to Ben. Moreover he was gentle enough to wait my geological times to integrate the patches...

I am very pleased to see people building upon my Lua bytecode research, and I wouldn't be surprised to see more applications with embedded Lua which are exploitable like this.

corsix explanation of the bug is here: https://gist.github.com/corsix/6575486

it is a very good write up. it was not too difficult to convert it to 64 bit.

i'm fairly sure the demo page on the lua website is vulnerable: http://www.lua.org/demo.html but lua-5.3 is a little different fro lua-5.1 so i don't have a working exploit for this. but they let you load bytecode.

nginx is the first thing that occurred to me?

Definitely, but Lua is specifically designed to be easily embeddable, it is used all over: https://sites.google.com/site/marbux/home/where-lua-is-used

Talk about transparency, thanks for sharing this so quickly Salvatore.

Thank you jonesetc, the min I can do is to acknowledge the great work of the researcher that found the issue and patched Redis! Thanks to his work we'll be a bit safer :-)

Why isn't POST a synonym for QUIT?

Sounds like a good idea... Does not fix everything but at least it should make it harder to exploit it without direct access.

This is a very neat idea :)

That's why you should never allow loading Lua bytecode. Disallowing it is trivial, don't know why they didn't do it.

Has there been any similar research on LuaJIT? It uses its own completely different bytecode.

Mike Pall has emphasized on various occasions that he believes that sandboxing Lua (while discussing LuaJIT issues, but refering to Lua in general) is reasonably possible only by considering the whole (OS) process as the sandbox: "The only reasonably safe way to handle untrusted Lua scripts is to isolate them in a process context and to make use of per-process quotas/limits provided by the operating system." (http://lua-users.org/lists/lua-l/2011-02/msg01106.html) - there were other occasions. However, I am not aware of a bytecode related discussion in this regard. And yes, it uses different bytecode - and a different intermediate representation.

You can see here: http://luajit.org/extensions.html that it uses different bytecode. There is a chance that it has a similar vulnerability.

It is very hard to sandbox lua properly. Embedded scripting sounds good, but in most cases is more of a liability.

When you let a program run other, externally provided programs, there are always risks. I agree. But in the case of Redis Lua scripting, the risks were definitely counter balanced by what the community did with this feature in the latest years. Today is hard to imagine Redis without Lua scripting capabilities.

It is much easier to sandbox Lua than most other scripting languages.

If you have a very adversarial security model, do not offer your users any chance to run in-process Turing-complete scripts. But if you do want that feature, Lua is the best language I can think of (at least that is not a LISP).

Lua bytecode has been known to be vulnerable for a long time, which is why there is no more bytecode sanitizer in the language. If you load untrusted code from Lua, always use mode "t". This is documented in Lua 5.3: http://www.lua.org/manual/5.3/manual.html#pdf-load

If you want to implement a Lua sandbox, start with this post by Lua author: http://lua-users.org/lists/lua-l/2013-12/msg00406.html and this repository by a prominent member of the Lua community: https://github.com/kikito/sandbox.lua

for most use cases it doesn't matter because you trust everyone who can connect to the redis server. however, it was possible to CSRF against dev's boxes and some people offer cloud redis and might not properly isolate the redis instances. probably most DBs that offer scripting languages are vulnerable to RCE.