Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 23 Feb 2014 12:02:38 -0500 (EST)
Subject: Re: Fwd: temporary file creation vulnerability in Redis

Hash: SHA1

> Could someone please assign me a CVE for the below Redis vulnerability?


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. 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, 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 ]
Version: GnuPG v1.4.14 (SunOS)


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.