Redishell: Critical Remote Code Execution Vulnerability in Redis

Why is this bad? Do you run user-authored lua scripts against your redis?

Do you have your redis exposed 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 nothing-burger to me and every redis setup I've ever used, all of which only run trusted lua scripts.

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...

https://github.com/valkey-io/valkey/releases/tag/8.1.4

Why would you assume that?

probably due to low exposure

Lua that isn't too old is not compatible with old Lua, unfortunately.

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.

To make these numbers meaningful, we would need to compare them to a similar software installations in Internet, like SQL databases.

That sounds like a bigger problem...

Interestingly it also breaks into RedisHell too.

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.

The number of redis setups out there which rely on user-uploaded lua scripts and the lua sandbox being sufficient for that has got to be... close to 0?

Like, the lua scripting feature is there for developers to write static trusted lua, check it in, and run transactional stuff etc, and so anyone uploading arbitrary user code as a script is already wildly outside of a normal use of redis.

Seems wild that something which requires using the thing wrong, and also which impacts close to 0 real deployments of the thing, gets a CVSS 10.

Basically guaranteed RCE for vulnerable configurations - a severity of 10 seems apt.

The aspect that it's only impacting a small percentage of installations in practice does not factor into the severity calculation.

OTOH I'd question the "Privileges required: low" part of the CVSS table. While out-of-box redis is vulnerable, typical deployments are secured by at least a password. Exploitation would need authentication or a separate auth bypass.

Most in-house redis deployments are probably safu if deployed according to best practices but Redis-as-a-service operators want to be on top of this.

IMO, this is rather poor reporting and feels a bit flashy for a security researcher to make a name for themselves.

While Redis seems vulnerable to this by default, most companies aren't deploying directly to the internet with terribly unsafe default configurations. Like, if you're vulnerable to this, you were already at major risk anyways.

fwiw, they're using CVSSv3. In CVSSv4, it's probably an 8.7: https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L...

The difference is meaningless. Both scores are high enough to warrant a significant response. For that, the score is fine.

Yep, however people don't configure things properly so many years ago I introduced a middle ground between not listening to * (which makes things harder for users in actual deployment systems) and leaving the server exposed, that is: protected mode. If Redis has the default configuration to bind all the addresses and no auth is configured, it refuses commands and informs you how to configure it properly. This avoided many security problems, and avoid also the feeling I always had as a user of other systems defaulting to binding to only local interfaces, where you need to understand what to do in order to make it reachable from other computers.

Interesting. Curious if anyone has more details on the PS5 Redis server? I did not know there was one running on the PS5; I wonder what the console uses it for.

Exactly, also requires authentication. How can this be 10/10?

They've been too busy adding multi threading.

If a trivial UAF existed for more than a decade, then I can't wait to see what smorgasbord of memory bugs they introduced with threads.