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: 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.
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]
CVE request: [1] http://www.openwall.com/lists/oss-security/2013/01/14/3
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.