Description of problem:
From Redis 3.2's release notes :
Redis 3.2.7 Released Tue Jan 31 16:21:41 CET 2017
Upgrade urgency HIGH: This release fixes important security and correctness
issues. It is especially important to upgrade for Redis
Cluster users and for users running Redis in their laptop
since a cross-scripting attack is fixed in this release.
Main bugs fixes and improvements in this release:
[... trimmed ...]
2. As Redis 4.0 beta and the unstable branch already did (for some months at
this point), Redis 3.2.7 also aliases the Host: and POST commands to QUIT
avoiding to process the remaining pipeline if there are pending commands.
This is a security protection against a "Cross Scripting" attack, that
usually involves trying to feed Redis with HTTP in order to execute commands.
Example: a developer is running a local copy of Redis for development
purposes. She also runs a web browser in the same computer. The web browser
could send an HTTP request to http://127.0.0.1:6379 in order to access the
Redis instance, since a specially crafted HTTP requesta may also be partially
valid Redis protocol. However if POST and Host: break the connection, this
problem should be avoided. IMPORTANT: It is important to realize that it
is not impossible that another way will be found to talk with a localhost
Redis using a Cross Protocol attack not involving sending POST or Host: so
this is only a layer of protection but not a definitive fix for this class
3. A ziplist bug that could cause data corruption, could crash the server and
MAY ALSO HAVE SECURITY IMPLICATIONS was fixed. The bug looks complex to
exploit, but attacks always get worse, never better (cit). The bug is very
very hard to catch in practice, it required manual analysis of the ziplist
code in order to be found. However it is also possible that rarely it
happened in the wild. Upgrading is required if you use LINSERT and other
in-the-middle list manipulation commands.
[... trimmed ...]
Redis 3.2.4 Released Mon Sep 26 08:58:21 CEST 2016
Upgrade urgency CRITICAL: Redis 3.2 and unstable contained a security
vulnerability fixed by this release.
Hello Redis Wizards of the Memory Stores Empire,
this is a Redis critical release in order to fix a security issue
which is documented clearly here:
Thanks to Cory Duplantis of Cisco Talos for reporting the issue.
The gist is that using CONFIG SET calls (or by manipulating redis.conf)
an attacker is able to compromise certain fields of the "server" global
structure, including the aof filename pointer, that could be made pointing
to something else. In turn the AOF name is used in different contexts such
as logging, rename(2) and open(2) syscalls, leading to potential problems.
Please note that since having access to CONFIG SET also means to be able
to change the AOF filename (and many other things) directly, this issue
actual real world impact is quite small, so I would not panik: if you
have CONFIG SET level of access, you can do more and more easily.
[... trimmed ...]
If anyone needs this fix, I've produced a COPR with a
fixed version (3.2.10 currently) for el6 and el7 here:
redis-3.2.10-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-07d2039ffa
redis-3.2.10-2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-07d2039ffa
redis-3.2.10-2.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.