[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201402231702.s1NH2c7P029650@linus.mitre.org>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
