Bug 1433968 - Redis 3.2.3 in EPEL 7 has multiple (including critical) security vulnerabilities
Summary: Redis 3.2.3 in EPEL 7 has multiple (including critical) security vulnerabilities
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: redis
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Nathan Scott
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-20 13:32 UTC by Tadej Janež
Modified: 2017-09-04 17:49 UTC (History)
4 users (show)

Fixed In Version: redis-3.2.10-2.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-04 17:49:26 UTC


Attachments (Terms of Use)

Description Tadej Janež 2017-03-20 13:32:54 UTC
Description of problem:

From Redis 3.2's release notes [1]:

================================================================================
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
   of issues.

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:

    https://github.com/antirez/redis/commit/6d9f8e2462fc2c426d48c941edeb78e5df7d2977

Thanks to Cory Duplantis of Cisco Talos for reporting the issue.

IMPACT:

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 ...]

[1] https://raw.githubusercontent.com/antirez/redis/3.2/00-RELEASENOTES

Comment 1 Nathan Scott 2017-08-15 06:53:08 UTC
If anyone needs this fix, I've produced a COPR with a
fixed version (3.2.10 currently) for el6 and el7 here:
https://copr.fedorainfracloud.org/coprs/nathans/redis3/

Comment 2 Fedora Update System 2017-08-18 01:30:09 UTC
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

Comment 3 Fedora Update System 2017-08-18 20:24:01 UTC
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

Comment 4 Fedora Update System 2017-09-04 17:49:26 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.