Bug 452100 (CVE-2013-0178, CVE-2013-0180) – <dev-db/redis-2.6.7: Two insecure temporary file use flaws (CVE-2013-{0178,0180})

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Agostino Sarubbo 2013-01-14 20:07:42 UTC]

From $URL :

Issue #1:
=========

  Michael Scherer in the following Red Hat bugzilla:
  [1] https://bugzilla.redhat.com/show_bug.cgi?id=894659

pointed out, Redis, a persistent key-value database of version 2.4
to be prone to temporary file use in src/redis.c:

  server.vm_swap_file = zstrdup("/tmp/redis-%p.vm");

[2] https://bugzilla.redhat.com/show_bug.cgi?id=894659#c0

Note: This problem was fix by the patch [3] below.

Issue #2:
=========
When searching for a patch, that corrected the issue [2]
above, found out it was patch

[3] https://github.com/antirez/redis/commit/697af434fbeb2e3ba2ba9687cd283ed1a2734fa5 ,

but it also introduced another insecure temporary flaw in
src/redis.c:

  776 	+    server.ds_path = zstrdup("/tmp/redis.ds");

Note: Issue #2 is also fixed in recent upstream 2.6.7 / 2.6.8
      versions. If you want me to find exact patch, which
      corrected the second problem, let me know and i will
      provide the commit id.

[Comment 1 Johan Bergström 2013-01-14 21:15:36 UTC]

1: Since we only have newer than 2.6.7 in tree, I'm therefore assuming that 2.6 is safe (from a gentoo perspective)?

2: Just checked the 2.4 branch, and this code at least still seems to be in there.  Here's the following commit to the offending line in unstable/2.6 branch: https://github.com/antirez/redis/commit/4ab988238f7418d018bf4412c6c956845ffbeab9

The two branches are diverging and neither patches will apply cleanly to a 2.4. Has this been reported upstream?

[Comment 2 Dirkjan Ochtman (RETIRED) 2013-01-24 12:03:41 UTC]

Johan, can you look for upstream reports for 2.4.x/report it upstream?

[Comment 3 Johan Bergström 2013-02-26 01:19:26 UTC]

fwiw, I emailed upstream at January 25th. No response yet.

[Comment 4 Dirkjan Ochtman (RETIRED) 2014-03-30 19:51:28 UTC]

Johan, any news here? Is this still relevant?

[Comment 5 Johan Bergström 2014-03-30 22:41:55 UTC]

Unfortunately no. I don't think upstream has officially "accepted" it. Haven't really found that any other distros seems to carry a patch for it. I could partly be blamed for not searching enough though.

[Comment 6 Thomas Deutschmann (RETIRED) 2016-11-23 19:31:25 UTC]

As of today, v2.4 branch is still affected: https://github.com/antirez/redis/blob/2.4/src/redis.c#L847. In other words we can expect that CVE-2013-0178 will be never fixed.

CVE-2013-0180 which was assigned for the same problem in v2.6 branch and got fixed according to "git log -S "/tmp" src/redis.c" (command must be run in 2.6 branch) when upstream removed diskstore via https://github.com/antirez/redis/commit/c9d0c3623a7714bd41a35237f4ba927206a7adb6.

$ git tag --contains c9d0c3623a7714bd41a35237f4ba927206a7adb6 | sort
2.6.0
2.6.0-rc1
2.6.0-rc2
2.6.0-rc3
2.6.0-rc4
2.6.0-rc5
2.6.0-rc6
2.6.0-rc7
2.6.0-rc8
2.6.1
[...]

...so I don't understand why a CVE was ever assigned for v2.6.0 because no v2.6 release ever tagged created something in /tmp.

Anyways, v2.6.7 was the first version which appeared in Gentoo repository not containing the flaw, see https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-db/redis/redis-2.6.7.ebuild?hideattic=0&view=log

As of today the first stable redis version in Gentoo repository is =dev-db/redis-2.8.17-r1 and no vulnerable versions left. So nothing left to do for us.


@ Security: Please vote!

[Comment 7 Aaron Bauman (RETIRED) 2016-11-25 06:01:30 UTC]

GLSA Vote: No