Re: Question about world readable config files and commented warnings

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 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.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJVkuc9AAoJEKllVAevmvmslpIIAIJw7DtVFdhBLVJubK4FGbwP
K5lkOO6LCwxojpLsXbj60mFJ7W7jaloLCYINYLBkKC2MalQ1t/sbcXClZ4LDkPUA
zC/fGYR1q1WOX/rz4IUM0BHpKunQsRBeuKMSn2Hj+fF1Aa90CnFQ45lAMhF+ybZK
vBNkws5v0UuIgKxVRqvQejsegWlLGlcaqfQ7Gd7Bgd78Mi0Q5dbpckjauofKUZB1
1K+lMAqvdX8hoy+i5QA23tx1xTtbp1d1StlnmbZkCtjYK2K9SwGMuZYou/dwSwQj
RMnc7me+aISzZ0jDjoXqoGYewIvy80mnMzbb5GX3vcnUUwOs9zZomnF+ymx3Bwg=
=0CLn
-----END PGP SIGNATURE-----