Redis is an in-memory database that persists on disk. Versions 7.0.0 and above, prior to 7.0.5 are vulnerable to an Integer Overflow. Executing an XAUTOCLAIM command on a stream key in a specific state, with a specially crafted COUNT argument may cause an integer overflow, a subsequent heap overflow, and potentially lead to remote code execution. This has been patched in Redis version 7.0.5. No known workarounds exist.
Redis is an open source, in-memory database that persists on disk. The redis-cli command line tool and redis-sentinel service may be vulnerable to integer overflow when parsing specially crafted large multi-bulk network replies. This is a result of a vulnerability in the underlying hiredis library which does not perform an overflow check before calling the calloc() heap allocation function. This issue only impacts systems with heap allocators that do not perform their own overflow checks. Most modern systems do and are therefore not likely to be affected. Furthermore, by default redis-sentinel uses the jemalloc allocator which is also not vulnerable. The problem is fixed in Redis versions 6.2.6, 6.0.16 and 5.0.14.
Potential heap overflow in Redis
Redis v7.0 was discovered to contain a memory leak via the component streamGetEdgeID.
redis v7.0.10 was discovered to contain a segmentation violation. This vulnerability allows attackers to cause a Denial of Service (DoS) via unspecified vectors.
(CVE-2022-36021) String matching commands (like SCAN or KEYS) with a specially crafted pattern to trigger a denial-of-service attack on Redis, causing it to hang and consume 100% CPU time. https://github.com/gentoo/gentoo/pull/29860
(CVE-2023-25155) Specially crafted SRANDMEMBER, ZRANDMEMBER, and HRANDFIELD commands can trigger an integer overflow, resulting in a runtime assertion and termination of the Redis server process. https://github.com/gentoo/gentoo/pull/29860
Redis is an in-memory database that persists on disk. Starting in version 7.0.8 and prior to version 7.0.10, authenticated users can use the MSETNX command to trigger a runtime assertion and termination of the Redis server process. The problem is fixed in Redis version 7.0.10.
(CVE-2023-25155) Specially crafted SRANDMEMBER, ZRANDMEMBER, and HRANDFIELD commands can trigger an integer overflow, resulting in a runtime assertion and termination of the Redis server process. https://github.com/gentoo/gentoo/pull/29860
(CVE-2022-36021) String matching commands (like SCAN or KEYS) with a specially crafted pattern to trigger a denial-of-service attack on Redis, causing it to hang and consume 100% CPU time. https://github.com/gentoo/gentoo/pull/29860
Redis is an in-memory database that persists on disk. Redis does not correctly identify keys accessed by SORTRO and as a result may grant users executing this command access to keys that are not explicitly authorized by the ACL configuration. The problem exists in Redis 7.0 or newer and has been fixed in Redis 7.0.13 and 7.2.1. Users are advised to upgrade. There are no known workarounds for this vulnerability.
DISPUTED A vulnerability, which was classified as problematic, was found in Redis up to 6.2.7/7.0.5. Affected is the function sigsegvHandler of the file debug.c of the component Crash Report. The manipulation leads to denial of service. The complexity of an attack is rather high. The exploitability is told to be difficult. The real existence of this vulnerability is still doubted at the moment. Upgrading to version 6.2.8 and 7.0.6 is able to address this issue. The patch is identified as 0bf90d944313919eb8e63d3588bf63a367f020a3. It is recommended to apply a patch to fix this issue. VDB-211962 is the identifier assigned to this vulnerability. NOTE: The vendor claims that this is not a DoS because it applies to the crash logging mechanism which is triggered after a crash has occurred.
It seems that redis 2.4 use a predictible file name in /tmp/ as some kind of swap file :
server.vmswapfile = zstrdup("/tmp/redis-%p.vm");
this was removed in 2.6 ( deprecated code ), but 2.4 is in fedora 18 and epel 6 AFAIK.
Since redis do not care if the file exist or not before opening it ( and in fact, I think it try to reuse if it already exist ), this could be used by a attacker to erase a arbitrary file with a symlink to the file. Depending if redis is running as root or not, this could be dangerous, or just a minor nuisance.
It was found that redis set weak permissions on certain files that could potentially contain sensitive information:
-rw-r--r--. 1 redis root 41599 Feb 8 2016 /etc/redis.conf -rw-r--r--. 1 redis root 7355 Feb 8 2016 /etc/redis-sentinel.conf drwxr-xr-x. 2 redis redis 4096 Sep 9 14:29 /var/lib/redis
This issue was originally reported in bug 1374700.