In 2015 I performed an offensive security analysis of Redis, focusing on its Lua scripting capabilities and related execution environment. This post contains a brief summary of my findings, which at the time have been reported and discussed with project maintainers.
Redis allows users to execute custom logic in the context of the server process, by using the Lua programming language.
It provides a restricted execution environment designed to prevent unsafe operations by Lua scripts.
Such restrictions are enforced by the server process in order to maintain security and stability, while allowing users to manipulate Redis data.
Redis tries to set up a safe Lua environment by restricting user access to the underlying Lua engine. In particular, it applies an allow-list for native Lua modules and functions that can be safely exposed to users.
However the existing allow-list is largely ineffective, because some of the exposed functions allow for global environment manipulation. This make it easy to bypass parts some further restrictions (eg. the "strict lua" mode) and to cause other internal state de-synchronization.
Bug report:
Using the technique above, I noticed that it is possible to de-synchronize the internal state of Lua and Redis. As an example, this allows to reliably trigger a DoS/crash by hitting an assertion.
Bug report:
Looking into Lua parsing logic, I discovered some bugs in the input-parsing code in lua_struct.c, namely an integer ovverflow and a type confusion between int and size_t.
This allows a malicious EVAL command to trigger a stack-based buffer overflow with (limited) user-controlled writes.
Bug report:
lua_struct.c