Bug 894659 (CVE-2013-0178)

Summary: CVE-2013-0178 redis 2.4: Insecure temporary flaw use for redis service's vm swap file
Product: [Other] Security Response Reporter: Michael Scherer <misc>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: jlieskov, jrusnack, security-response-team, silas
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: impact=low,public=20130114,reported=20130112,source=researcher,cvss2=1.9/AV:L/AC:M/Au:N/C:N/I:P/A:N,fedora-all/redis=affected,epel-all/redis=affected,cwe=CWE-377
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-22 02:56:21 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 895121, 895120    
Bug Blocks:    

Description Michael Scherer 2013-01-12 17:55:31 EST
It seems that redis 2.4 use a predictible file name in /tmp/ as some kind of swap file :

    server.vm_swap_file = 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.
Comment 1 Jan Lieskovsky 2013-01-14 09:43:55 EST
Thank you for this report, Michael. I am going to steal this bug to be a security response product (as there are more products affected by this issue than just upcoming Fedora-18).
Comment 2 Jan Lieskovsky 2013-01-14 09:50:58 EST
This issue affects the versions of the redis package, as shipped with Fedora release of 16 and 17.

--

This issue affects the versions of the redis package, as shipped with Fedora EPEL 5 and Fedora EPEL 6.
Comment 3 Jan Lieskovsky 2013-01-14 10:46:32 EST
The upstream patch which fixed the "/tmp/redis-%p.vm" insecure flaw (but also introduced different one in "/tmp/redis.ds") is the following one:
  https://github.com/antirez/redis/commit/697af434fbeb2e3ba2ba9687cd283ed1a2734fa5

So to fix this issue it would be easier to rebase to latest 2.6.* version, which doesn't contain the issue any more.
Comment 4 Jan Lieskovsky 2013-01-14 10:48:23 EST
Michael, since there is an upstream patch for this issue available already (latest 2.6.* version is not affected by this problem), would you mind if we would open this bug and request CVE identifier for it publicly?

Let us know. Thank you, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team
Comment 5 Michael Scherer 2013-01-14 10:53:23 EST
No problem for me.
Comment 6 Jan Lieskovsky 2013-01-14 10:54:59 EST
(In reply to comment #5)
> No problem for me.

Thank you. Will request CVE id shortly.
Comment 7 Jan Lieskovsky 2013-01-14 10:58:39 EST
Created redis tracking bugs for this issue

Affects: fedora-all [bug 895120]
Affects: epel-all [bug 895121]
Comment 8 Jan Lieskovsky 2013-01-14 11:11:42 EST
CVE request:
[1] http://www.openwall.com/lists/oss-security/2013/01/14/3
Comment 9 Vincent Danen 2013-01-15 11:51:05 EST
Two CVEs were assigned here:

http://www.openwall.com/lists/oss-security/2013/01/14/7

CVE-2013-0178 for the insecure /tmp usage in 2.4
CVE-2013-0180 for the insecure /tmp usage in 2.6

Since we only ship 2.4-based versions, only noting the first CVE as applicable to us in this bug.