Re: Question about world readable config files and commented warnings

[Kurt Seifried <kseifried () redhat com>]

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 () mitre 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 () canonical 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 () redhat com

Attachment: signature.asc
Description: OpenPGP digital signature