Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Jun 2015 15:03:36 -0400 (EDT)
Subject: Re: Question about world readable config files and commented warnings

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

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 <>
> 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 ]
Version: GnuPG v1.4.14 (SunOS)


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.