hckrnws
A post-auth memory corruption vulnerability scores a CVSS 10. Shellshock got like a 9.5. These scores don't mean anything.
You can imagine a post-auth Redis vulnerability being deceptively well-exposed, because web apps often give partial control of the Redis key space to attackers, and don't care how long you make your strings. But this one is a UAF that requires attackers to send a malicious Lua script.
Agreed, adding to this, if a malicious actor already has the ability to execute arbitrary LUA scripts on your redis instance, then you are probably already pretty screwed.
I've got nothing bad to say about the vuln research here, I'm sure it's a great bug, just this CVSS stuff is a farce and everyone seriously working in the field seems to agree, but we're just completely path-dependently locked in to it.
If the Lua "sandbox" is actually a decent sandbox, then the most you could do before was DoS the box. DoS <<<<< RCE
That is unfortunate there's so many Redis instances out there that not only are exposed to the public internet (330,000) and don't have authentication configured (60,000). I'm guessing those folks probably didn't even realize their Redis was public.
There are so many tutorials out there for things like Docker Compose that cause people to bind a service to 0.0.0.0 with a port open to the public internet.
In hindsight, making the default listening address for port forwards in docker(-compose) 0.0.0.0 instead of 127.0.0.1 was/is such a pain point for me. Every time I work with it for servers as almost always it should not be directly exposed (usually services are behind a host-side NGINX rev proxy).
It also likely has yielded far too many (unintentionally) open services, especially considering dockers known firewall woes with bypassing of existing rules.
That sounds like a bigger problem...
Seems similar in impact to https://nvd.nist.gov/vuln/detail/cve-2021-32626, I wonder why this has a CVE 10.
This code also looks generally fixed in Lua5.4, https://github.com/lua/lua/blame/9ea06e61f20ae34974226074fc6.... Valkey and Redis really need to move to Lua that isn't so old.
"RediShell" is an absolutely horrible name that makes it extremely difficult to search for things.
Post-auth, so this shouldn't be CVSS 10 (highest possible score), because that implies pre-auth RCE would not be more critical..
Good news that it was found and fixed, but 140 days response time seems rather slow for such a critical vulnerability
I'm assuming this has also been addressed in Valkey and most prominent forks as well.
Looks like the fix was committed three days ago and they cut a release for version 8.1.4.
https://github.com/valkey-io/valkey/commit/6dd003e88feace83e...
Why would you assume that?
I'm assuming this is why Ubuntu's unattended-upgrades service uncerimoniously restarted the redis-server process on my machine late September?
yikes, this is bad
Would think most forks would be affected as well (?)
Why is this bad? Do you run user-authored lua scripts against your redis?
Do you have your redis expose without any authentication on the public internet?
If you do either of those, sure, this is bad for you.
I've worked with quite a few redis setups and know the details of even more, I do not know a single redis setup which would be vulnerable to this.
I've never heard a single instance of someone deciding that redis's lua sandbox is secure enough that they'll let their users upload arbitrary lua code and run it, and trust the lua sandbox to keep that redis box safe.
Like, because it's a use-after-free in the lua environment which requires a malicious lua script, this is just such a giant nothingburger to me and every redis setup I've ever used, all of which only run trusted lua scripts.
Crafted by Rajat
Source Code