Date: Sun, 23 Feb 2014 12:02:38 -0500 (EST) From: cve-assign@...re.org To: mhall@...omputing.net Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: Fwd: temporary file creation vulnerability in Redis -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Could someone please assign me a CVE for the below Redis vulnerability? > https://github.com/antirez/redis/issues/1560 Our understanding so far is that this doesn't cross privilege boundaries within the context of the product's documented security model, so no CVE assignment is pending. Admittedly, the documentation doesn't specifically address the "Is it always completely safe to put 'dir /tmp/' in redis.conf?" question. Note that the value is "dir ./" in the default redis.conf file. http://redis.io/topics/security says "Redis is designed to be accessed by trusted clients inside trusted environments ... in general, untrusted access to Redis should always be mediated by a layer implementing ACLs." It also says "the ability to control the server configuration using the CONFIG command makes the client able to change the working dir of the program and the name of the dump file. This allows clients to write RDB Redis files at random paths, that is a security issue that may easily lead to the ability to run untrusted code as the same user as Redis is running." Yes, the documentation is primarily talking about access over the network, not access within a multi-user system that has potentially untrusted local user accounts. However, apparently in the default configuration, a local user can simply connect to 127.0.0.1, send "CONFIG SET dir" and "CONFIG SET dbfilename" commands, and then send a BGSAVE command to overwrite an arbitrary file with the privileges of the Redis process. The vendor considers this intended behavior because of the "trusted clients inside trusted environments" statement in the security model. Because of this, it seems most likely that the trusted-environment constraint also means that direct filesystem write access to the product's data directory is also outside the scope of the security model. So, we are not planning to assign a CVE ID unless the vendor decides to announce the temp-%d.rdb issue as a vulnerability. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJTCijJAAoJEKllVAevmvmsNrAH+gPNX5rY89Z0nsC3N9JlZFQC 4O0xvDcgaOQY5r6Pk25NfkabRn8A1q/37JOvqoED+iqA5mvQCqGNPTqlnlQAjJdO YUWqRBL6s8FIcj5nWvLB1FvTCIvrXPjaGBnKlgTGLBKJUsp4b+Ammer1yWEqIU0+ ocy9K2ewlkOjc7YfnlDHuw+7aB3ZOH8XrfF6OKnENsAibW53jqYwxicc+A0inkK9 ui45DQ4HNycRPP5oIplObFL1imPC1SEoTDw04vfxLrEoCDw/st5DyApUuYHfG6cJ hjf8FDxg2jZtv29YuZAb2fgEEkxH9dQ08c2GfJiMY0+nDdWzJgP8YMLnCzsZFXw= =jzUP -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ