CVE-2023-45145: Redis Race Condition Vulnerability

CVE-2023-45145 Overview

CVE-2023-45145 is a race condition vulnerability in Redis, the popular in-memory database that persists on disk. During startup, Redis begins listening on a Unix socket before adjusting its permissions to the user-provided configuration. When a permissive umask(2) is used, this creates a time-of-check time-of-use (TOCTOU) race condition that enables another process to establish an otherwise unauthorized connection during a brief window of opportunity. This vulnerability has existed in Redis since version 2.6.0-RC1.

Critical Impact
Local attackers with access to the system can exploit the race condition during Redis startup to establish unauthorized connections to the Unix socket, potentially gaining access to sensitive data or performing unauthorized operations on the database.

Affected Products

Redis versions from 2.6.0-RC1 up to 7.2.1, 7.0.13, and 6.2.13
Fedora Linux 37, 38, and 39
Debian Linux 10.0

Discovery Timeline

2023-10-18 - CVE-2023-45145 published to NVD
2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-45145

Vulnerability Analysis

This vulnerability is classified under CWE-668 (Exposure of Resource to Wrong Sphere), stemming from improper handling of Unix socket permissions during Redis server initialization. The core issue lies in the sequence of operations: Redis creates and binds the Unix socket before applying the configured permissions, leaving a window where the socket is accessible based on the system's default umask rather than the intended restrictive permissions.

The attack requires local access and the ability to time the connection attempt precisely during Redis startup. While the exploitation window is narrow, automated scripts could repeatedly attempt connections during service restarts, increasing the likelihood of successful exploitation. A successful attack could lead to limited unauthorized access to Redis data or the ability to execute Redis commands without proper authorization.

Root Cause

The root cause is a classic Time-of-Check Time-of-Use (TOCTOU) vulnerability in the Unix socket initialization sequence. Redis creates the socket file and begins accepting connections before it has an opportunity to set the user-specified permissions. If the system uses a permissive umask (such as 0000 or 0022), the socket file is created with overly permissive access rights during this brief window.

The fix, implemented in commit 03345ddc7faf7af079485f2cbe5d17a1611cbce1, addresses this by ensuring proper permission handling during the socket creation process, eliminating the race condition window.

Attack Vector

The attack vector requires local access to the system running Redis. An attacker would need to:

Monitor for Redis service restarts or initiate a restart if possible
Rapidly attempt connections to the Unix socket during the startup sequence
Exploit the brief window when permissions are not yet restricted
Once connected, perform unauthorized operations against the Redis instance

The exploitation mechanism relies on timing and system configuration, making it more opportunistic in nature. In environments with frequent service restarts or where attackers can trigger restarts, the risk increases.

// Exploitation mechanism (conceptual description)
// During Redis startup, the Unix socket is created with umask-derived permissions
// before the configured restrictive permissions are applied.
// An attacker script could continuously attempt socket connections:
// 1. Wait for socket file creation at /var/run/redis/redis.sock
// 2. Attempt rapid connection before permissions are tightened
// 3. If successful during the race window, maintain the connection
// 4. Execute unauthorized Redis commands through the established connection

Detection Methods for CVE-2023-45145

Indicators of Compromise

Unexpected connections to the Redis Unix socket from unauthorized processes or users
Anomalous Redis command execution patterns immediately following service restarts
Log entries showing connections established during the brief startup window
Processes with unexpected Redis socket file descriptors

Detection Strategies

Monitor Redis logs for connection events during startup sequences
Implement file integrity monitoring on the Redis socket file to detect permission changes
Audit system processes that maintain connections to the Redis Unix socket
Configure alerting for Redis service restarts followed by unusual connection patterns

Monitoring Recommendations

Enable Redis connection logging and monitor for connections from unexpected sources
Implement system-level auditing on the Unix socket file path
Monitor process connections to Redis sockets using tools like lsof or ss
Set up alerts for multiple rapid connection attempts during service initialization

How to Mitigate CVE-2023-45145

Immediate Actions Required

Upgrade Redis to version 7.2.2, 7.0.14, or 6.2.14 or later immediately
Review and restrict the umask setting for the Redis service to ensure restrictive default permissions
Audit current Redis Unix socket permissions and access patterns
Consider disabling Unix sockets temporarily if TCP connections are sufficient for your use case

Patch Information

Redis has released patched versions addressing this vulnerability. Users should upgrade to:

Redis 7.2.2 or later for the 7.2.x branch
Redis 7.0.14 or later for the 7.0.x branch
Redis 6.2.14 or later for the 6.2.x branch

The fix is tracked in the GitHub Redis Commit. Additional details are available in the GitHub Security Advisory.

Linux distribution users should check for updated packages via their package managers. Fedora and Debian have issued updates as noted in the Debian LTS Announcement and Fedora Package Announcements.

Workarounds

Disable Unix sockets entirely by removing or commenting out the unixsocket directive in redis.conf
Start Redis with a restrictive umask (e.g., umask 077) to ensure minimal default permissions
Store the Unix socket file in a protected directory with restricted access permissions
Use systemd service hardening to restrict access to the Redis socket path

bash

# Configuration example - Restrictive umask for Redis service
# Add to Redis systemd service file (/etc/systemd/system/redis.service.d/override.conf)
[Service]
UMask=0077

# Alternative: Disable Unix socket in redis.conf
# Comment out or remove the following line:
# unixsocket /var/run/redis/redis.sock

# Or store socket in protected directory with restricted permissions
# mkdir -p /var/run/redis-protected
# chown redis:redis /var/run/redis-protected
# chmod 700 /var/run/redis-protected
# Then configure: unixsocket /var/run/redis-protected/redis.sock