
Redis Lua sandbox escape - antirez
http://benmmurphy.github.io/blog/2015/06/04/redis-eval-lua-sandbox-escape/
======
antirez
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...

------
corsix
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.

~~~
hughw
nginx is the first thing that occurred to me?

~~~
juliangregorian
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](https://sites.google.com/site/marbux/home/where-lua-is-used)

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

~~~
antirez
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 :-)

------
geocar
Why isn't POST a synonym for QUIT?

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

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

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

~~~
hwh
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](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.

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

~~~
antirez
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.

~~~
catwell
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](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](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](https://github.com/kikito/sandbox.lua)

