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.