[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140224035256.GA11529@mhcomputing.net>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
