[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150502151418.GA17491@sisay.ephaone.org>
Date: Sat, 2 May 2015 17:14:19 +0200
From: Michael Scherer <misc@...b.org>
To: oss-security@...ts.openwall.com
Cc: security@...ible.com
Subject: Re: Re: CVE Request / Ansible: insecure permission
on a directory when using spacewalk inventory
On Sat, May 02, 2015 at 08:54:10AM -0500, James Cammarata wrote:
> Hi Michael,
>
> Thanks for finding this and fixing it, however we're not sure if this
> requires a CVE?
The CVE is just a way to track the issue. Not all problem with a CVE requires
a immediate update ( or even a update at all ), even if people think
"there is a CVE so we must fix fast".
I do not consider it critical either to be handled privately, hence the cc to
oss-sec to get the opinion of others.
> First of all, the impacted script is an optional inventory
> script, which is not packaged with Ansible directly and must be downloaded
> from the source repository.
I use the git repo, so indeed, I didn't see that.
> Second, the script (as you mentioned) creates
> this directory typically in a relatively secure location, so the chances of
> it being exposed are greatly lessened. Also, this is a relatively
> under-utilized script, as not many people that we know of are getting host
> information from Spacewalk using this script. Finally, the data contained
> within that cache file is not very sensitive, and would typically only
> contain the host IP information of systems from Spacewalk.
One potential attack is also that someone inject data in the cache, since
the file is open without checking for permission, either read or write.
So if I inject in the cache a server that I control, I can make ansible
connect to it, and make it deploy a role with password/certificate
that I may not be able to access usually.
So the impact is potential information disclosure, not on spacewalk
level, but on the ansible level.
One example of such setup (minus the spacewalk thing) would Fedora, where only
few people have access to the private information and everybody is required
to use ansible via sudo on a shared bastion to make changes. And where most people
do not have root access to all servers. I think such tiered access schemes are
not that uncommon.
So yeah, it is a very specific scenario, and the combination of using spacewalk
and that use case make it unlikely to be a problem in practice for most people,
so it is not critical to fix right away, I agree. But still a CVE would be useful
for tracking.
> If a CVE is issued, we can mention it in the release, but we'd much rather
> simply fix this ASAP and include it in the next major/minor release of
> Ansible (2.0 and 1.9.2, respectively).
2.0 is not ready, so the real question is around 1.9.2, is it planned to
be out very soon ? What about saying "we wait a few days for the CVE", and
then merge the patch if the CVE is not assigned by the 5th of may ?
--
Michael Scherer
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.
