[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
