[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Jun 2015 14:36:22 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: cve-assign@...re.org
CC: oss-security@...ts.openwall.com, seth.arnold@...onical.com
Subject: Re: Question about world readable config files and commented warnings
So in past these got CVE's, e.g.
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=config+file+permissions
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=weak+permissions+password
and so on.
So has policy changed for the specific case of:
Configuration file takes a password and has world readable permissions
by default (and let's assume no explicit warning in the comments in the
config file).
Thanks
On 06/30/2015 01:03 PM, cve-assign@...re.org wrote:
>> so does a situation where the author creates the config file with
>> that warning, and then a vendor repackages and ships it, still world
>> readable, still with the warning, warrant a CVE?
>
> No, in general, repackaging doesn't mean that there can be new CVEs as
> a result of a reevaluation of whether any part of a product's
> configuration/behavior would have been chosen differently if it had
> been the repackager's own original code.
>
> There can, however, be new CVEs for new interaction errors. For
> example, if a Linux distribution shipped that product with upstream's
> standard default config-file permissions, but simultaneously shipped a
> setup tool that required a password in the database URI (without
> addressing file permissions during setup, and without showing the file
> contents to the user), then there would need to be a CVE for
> something, because there is no way to use that combination safely.
> Most likely the CVE would name the setup tool as the primary affected
> product/component.
>
> This would apply in essentially the same way if it weren't a
> standalone setup tool, but were instead a module for a larger
> configuration-management product. If a module is intended to modify
> configuration files, it seems that the module author has (at least
> some) responsibility for avoiding introduction of vulnerabilities into
> the configuration. This configuration-management module topic may have
> some open questions. However, as far as we know, people haven't been
> submitting many CVE requests about vulnerabilities that were caused
> when a module didn't incorporate complete knowledge of
> configuration-file semantics.
>
>> Date: Tue, 30 Jun 2015 11:04:04 -0700
>> From: Seth Arnold <seth.arnold@...onical.com>
>
>> Did the vendor also fill in a password? If so, that's worth a CVE to me.
>
> We agree that this is a straightforward case that would have a CVE.
> This is, more or less, an extreme example of the setup-tool case
> described above: either way, the vendor has forced the product into an
> always-unsafe state.
>
>
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@...hat.com
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
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.
