[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 14 Dec 2015 16:42:06 -0500
From: Jan Schaumann <jschauma@...meister.org>
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org
Subject: Re: Re: Chef: knife bootstrap leaks validator privkey
into system logs
cve-assign@...re.org wrote:
> In general, an issue with unlogged private data on a command line
> sometimes does not have a CVE ID, if the command line only occurs
> during initial installation of a machine, before any unprivileged user
> accounts would have access. (We don't know enough about the use cases
> to determine whether that sometimes applies to chef.)
It's possible that Chef is installed/bootstrapped on a system that is
already configured/set-up and used by other users.
User management may be done entirely outside of Chef, so that there is
no universal guarantee that Chef would only ever be installed when no
other unprivileged users would have access to the system (even if that
is likely to be the majority of the use cases).
> > https://github.com/chef/chef/issues/3872
> >
> > creates private files via here-doc cat(1)ing followed by running
> > chmod(1) and setting the permissions.
> >
> > This is a race condition if the default umask creates files world- or
> > group-readable (as is almost universally the case).
>
> 3872 was linked from 3871. If there is a race-condition vulnerability
> disclosed in 3872, we may be able to assign a CVE ID. (We would not
> want a CVE if the issue can occur only before unprivileged user
> accounts would have access.)
As above: no such guarantee, even though most people may well bootstrap
Chef only in such environments.
-Jan
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.
