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.
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).
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.
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:
So to fix this issue it would be easier to rebase to latest 2.6.* version, which doesn't contain the issue any more.
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
No problem for me.
(In reply to comment #5)
> No problem for me.
Thank you. Will request CVE id shortly.
Created redis tracking bugs for this issue
Affects: fedora-all [bug 895120]
Affects: epel-all [bug 895121]
Two CVEs were assigned here:
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.