Date: Sun, 23 Feb 2014 19:52:56 -0800 From: Matthew Hall <mhall@...omputing.net> To: cve-assign@...re.org Cc: oss-security@...ts.openwall.com Subject: Re: Fwd: temporary file creation vulnerability in Redis On Sun, Feb 23, 2014 at 12:02:38PM -0500, cve-assign@...re.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
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