
Redis Lua scripting: several security vulnerabilities fixed - itamarhaber
http://antirez.com/news/119
======
mathnmusic
> Honestly when the Redis Lua engine was designed, it was not conceived with
> this security model of the customer VS the cloud provider in mind. The
> assumption kinda was that you can trust who pokes with your Redis server. So
> in general the Lua libraries were not scrutinized for security. The feeling
> back then was, if you have access to Redis API, anyway you can do far worse.

This is an interesting point. Cloud computing and managed/hosted services
require a clear separation of what the host can do and what the customer
(who's paying for the managed service) should be able to do.

Just today, our startup decided to use AWS Kinesis (as opposed to setting up
Kafka ourselves), despite the vendor lock-in and closed-source nature of AWS
components. :-/

~~~
zokier
Yeah, these sorts of questions are typically something that goes under the
umbrella of "multi-tenancy"; having proper access controls, isolation,
accounting, logging, security model, etc, which incidentally also makes even
trivial software explode with complexity. I haven't been paying attention, but
I would have not thought Redis to be multi-tenant ready out of the box.

------
samatman
Consensus in the community is that Lua(JIT) sandboxing must be done on the
process level.

Even with the debug library stripped and other safeguards against (inner)
evaluation taken, the trivial DOS of `while true do end` remains.

If that happens, you want it to live in its own process, or at least its own
thread.

~~~
antirez
Those kind of dos (while true do end), actually we handle quite well already,
because we don't use LuaJIT but plain Lua that has hooks that allow Redis to
detect such conditions. But in general, it's a "can of worms" indeed.

~~~
cjcole
Are your Lua changes public? I couldn't find a relevant repo. Thanks.

~~~
antirez
Yes but there is no direct modification to the Lua code, we just install the
hooks from the Redis source code using the Lua interpreter. So the
implementation of that is directly inside the Redis source tree, scripting.c
file.

------
breakingcups
I appreciate the (what feels like) honest and direct communication from
Antirez very much. It's always such a breath of fresh air.

------
moby
Heroku's updated their Redis fleet: [https://blog.heroku.com/redis-
vulnerability](https://blog.heroku.com/redis-vulnerability)

------
ksec
Somewhat off topic:

What Happened to the mRuby Scripting in Redis? I remember there were plans to
make mRuby in Redis too. Given mRuby has had quite a bit of security audit in
recent years that cost Shopify millions.

------
andrewmcwatters
> To be fair, I think that the assumptions Lua makes about the stack are a bit
> too trivial, with the Lua library developer having to constantly check if
> there is enough space on the stack to push a new value.

What the fuck? This is almost never a concern for Lua C developers. If you're
concerned with LUA_MAXCSTACK defaulted at 2048 and you're running out of
space, you're doing something seriously wrong and need to reevaluate how
you're using the Lua C API.

~~~
antirez
Hello Andrew, unfortunately the max limit is hit only if you make sure to call
the appropriate function that will reallocate the stack if needed. I think
that it would be saner for Lua, by default, just to accept stack pushes and
resize the stack if needed. I've the feeling that this would not be a huge
performance issue because most of the times it's just a check and no
reallocation is needed. As I wrote in the blog post, note that other languages
do not force you to think at such low level when using their C API. In general
Lua implementation is great, but the API exposing the stack, really poses just
a barrier that I feel is kinda pointless compared to providing the classical
argv/argc API of Python, Ruby, Tcl, ...

~~~
MattJ100
The reasoning behind not automatically growing the stack was given by the Lua
authors recently: [http://lua-
users.org/lists/lua-l/2018-04/msg00036.html](http://lua-
users.org/lists/lua-l/2018-04/msg00036.html)

~~~
antirez
Thanks for the relevant info.

