Date: Tue, 30 Jun 2015 15:03:36 -0400 (EDT) From: cve-assign@...re.org To: kseifried@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, seth.arnold@...onical.com Subject: Re: Question about world readable config files and commented warnings -----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@...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. - -- 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-----
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.