On: An unexpected Redis sandbox escape affecting Debia...

[benmmurphy]

I think this is still 'broken' because Redis have applied custom patches to the Lua source code in order to prevent sandbox escapes. If Debian Redis is using the normal Lua then these patches will not have been applied.

https://github.com/redis/redis/commit/49efe300af258e83f377cd...

and you can check the history on that file to see they haven't removed the fix:

https://github.com/redis/redis/commits/unstable/deps/lua/src...

it could be the latest lua version that Debian ships with has 'safe' byte code evaluation and this fix no longer needs to be applied.

[mikemike → benmmurphy]

Yes, of course it's vulnerable, verified with Docker debian:sid. That was my first reaction when I read this, but I wanted to verify it first. You beat me with this post.

Since you've already let the cat out of the hat (which is not ideal), please file the bugs at Debian and Ubuntu.

Test command:

    redis-cli eval 'return select(2, loadstring("\027")):match("binary") and "VULNERABLE" or "OK"' 0

While we're at it, redis has ignored the advice at: http://lua-users.org/wiki/SandBoxes Almost all of the critical functions (loadstring, load, getmetatable, getfenv, ...) are present and unprotected in the redis 'SandBox' (which isn't).

Which means, disable scripting or shut down your redis instances NOW, which do not run with the same privileges as any client which has access to this. Scripting can be disabled by renaming the EVAL and EVALSHA commands to unguessable names.

[reginaldo → mikemike]

I reported the "loadstring accepts arbitrary bytecode" issue back to Debian and Ubuntu.

But, just to clarify, mikemike's advice is that everyone (i.e. including people running upstream redis) should disable scripting.

[throwaway81523 → reginaldo]

Scripting in redis is important since it is how you get transactions.

[tedunangst → mikemike]

I don't think getmetatable et al are really problems, are they? You can mess things up in the sandbox, but that's not escaping it. I think that page is trying to build a sandbox where even a lua script can eval other lua code without blowback, but that's not what redis is trying to achieve.

[josephcsible → mikemike]

While you're right about the binary loadstring issue, that lua-users page is way overly paranoid. The best Lua sandboxing implementation I know of is the one Wikipedia uses, and it allows a lot of what's "unsafe" there.

[adamc → josephcsible]

Not really usually to call something "overly paranoid" without going into why you think their evaluation is wrong.

[tedunangst → adamc]

The page is trying to build a sandbox where a lua script can eval other untrusted lua code within the same lua execution environment. Many, even most?, people are only interested in isolating the host application from the lua environment.

[josephcsible → adamc]

Because there's ways to build safe sandboxes that allow untrusted code to use a bunch of things that it calls unsafe.

[bawolff → benmmurphy]

Given that lua is meant to be an embedded language, its kind of surprising this is neccesary.

[tedunangst → bawolff]

Making an application scriptable doesn't always mean you want it to be scriptable by hostile adversaries.

[bawolff → tedunangst]

That's what i mean. For an embedded scriptable language, making something scriptable and sandboxed is a core use case. It is surprising to me that doing the thing lua is famous for requires source code mods.