Redis Lua scripting: several security vulnerabilities fixed
antirez.com
antirez.com
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. :-/
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.
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.
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.
I agree with you that needing to keep track of the stack size is a pain though. I also wish it would just grow on demand as needed. That said, when you are doing things "by hand" the default stack limit of 10 slots per function call frame is often enough. It could be worse :)
Reviewing the commit in question: you have a function that blindly accepts any number of arguments. ~2047 arguments in a function is not an acceptable design choice for Lua. I can't see any language where I'd design an API for users where they could insert an upwards of ~2047 arguments and say to myself that's a good idea.
Your misuse of the Lua C API here does not grant a special use case, nor does it justify entire language implementation changes.
Your number one concern for hardening starts at the stack? And further more you think it's a good idea to compile a custom version of Lua it to avoid stack issues instead of just writing sane bindings? You would really go out of your way to do this?
Maybe instead of saying there's a problem with X, Y or Z, ask yourself if you're doing something wrong first.
Allow developers to pass in a table of values to pack instead of an arbitrary amount of arguments, push the values by index onto the stack, work with them, then pop them off. How is this difficult? What makes your use case special? Why would you avoid conventional Lua use?
vararg (..., select, {...} convention) usage in Lua almost always involves the use of tables.
The otherwise timid and passive voice on HN is frequently an irritation to me. This is the author of Redis making an uninformed decision in both writing Lua bindings, and extending that ignorance to making changes to Lua to suit his ignorance. I don't care. What my tone is suggesting is how ludicrous this is and how it shouldn't be taken as a good suggestion.
This is a great example of someone who has a large exposure simply using something incorrectly and him having a large exposure doesn't make his technical observations of a language meaningful. In no way here can you leverage that to justify poor decision making.
Keeping the stack on the lua_State has clear advantages, such as allowing the library to be reentrant. Handling malloc and free in a single pass for each lua_State is simpler than alternatives and fits well-enough with existing practices.
Second observation: LuaJIT might be the better platform to pursue this approach. Since the tracer is already on, stack overflows could potentially be another cold path that gets handled on spill; performance impact could be minimal, perhaps none if existing trace guards can be used.