Re: Fwd: temporary file creation vulnerability in Redis

[Matthew Hall <mhall () mhcomputing net>]

On Sun, Feb 23, 2014 at 12:02:38PM -0500, cve-assign () mitre org wrote:
> 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.

Hello,

As I'm sure you'd expect, I partly agree and disagree with this. I believe 
this security model is not very realistic because it disagrees with some of 
the product's own configuration file directives and popular usage.

Throughout the example configuration file are various directives and their 
default socket listen parameters whose descriptions and defaults appear to 
contradict their own security model's theories, and these are a default part 
of the product, while the security model is separate, and not part of the 
product.

1. The "requirepass" directive is intended to, "be useful in environments in 
which you do not trust others with access to the host running redis-server."

2. The "command renaming" feature is intended to, "[rename commands] into 
something hard to guess so that it will still be available for internal-use 
tools but not available for general clients."

3. They also note that, "[b]y default Redis listens for connections from all 
the network interfaces available on the server," i.e. with 0.0.0.0 (and ::/0 
in newer versions), which contravenes the trusted client trusted server model. 
If they are really expecting a high level of trust against the network, much 
less malicious users, this should be 127.0.0.1 (and perhaps ::1/128).

To me, in open source, things which are part of the code normally take 
supremacy over external documentation which often doesn't keep up with the 
rapid evolution of usage and featuresets which can happen in emerging open 
source products.

However, if you feel the security model still takes precedence over these 
other configuration directives and default communication parameters, I can 
understand and accept this view even though I might see it a differently.

But in that instance, it's important to clearly point out that many popular 
uses of the product, for any data than more sensitive than general public 
domain knowledge, could easily be unsafe and against the product's intent.

Regards,
Matthew Hall