Ansible versions before 1.9.2 are vulnerable to a symlink attack that enables a malicious zone/chroot/jail managed by ansible to escape into the managing host. Upstream commits that fix this issue: https://github.com/ansible/ansible/commit/548a7288a90c49e9b50ccf197da307eae525b899 https://github.com/ansible/ansible/commit/270be6a6f5852c5563976f060c80eff64decc89c https://github.com/ansible/ansible/commit/952166f48eb0f5797b75b160fd156bbe1e8fc647 https://github.com/ansible/ansible/commit/0777d025051bf5cf3092aa79a9e6b67cec7064dd https://github.com/ansible/ansible/commit/ca2f2c4ebd7b5e097eab0a710f79c1f63badf95b CVE request: http://seclists.org/oss-sec/2015/q3/105 External References: http://www.ansible.com/security
Created ansible tracking bugs for this issue: Affects: fedora-all [bug 1243469] Affects: epel-all [bug 1243470]
Additionally it was reported that versions of Ansible prior to 1.9.2 fail to adequately validate HTTPS certificates when using the get_url and uri modules, and when using the url and etcd lookup plugins. This allows for man-in-the-middle attacks on those connections. The fix for this problem has been released as part of Ansible 1.9.2. The Ansible playbook below is a proof-of-concept that can be used to safely validate the incorrect behaviour: - name: a playbook demonstrating MITM in ansible hosts: 127.0.0.1 connection: local tasks: - name: this should fail get_url: url=https://kennethreitz.org/ dest="/tmp/shouldnotexist.html” This playbook attempts to download a HTML file from a site presenting a certificate that is valid, but not for the site in question. Versions of Ansible from 1.9.2 onward correctly fail to validate the certificate, but earlier versions will download the file regardless and the playbook will successfully exit. This issue was assigned CVE-2015-3908: http://seclists.org/oss-sec/2015/q3/106
Another CVE assignment: http://seclists.org/oss-sec/2015/q3/378
Adam Mariš - thanks for watching this -- I'm not on oss-seclist but I ocncur with their assessment (There's only one bug. that bug was present in several ansible connection modules. the fix for each was roughly the same code. Only the first commit hash is part of the fix for the security issue. The other commits were only to fix non-security bugs and limitations in the initial fix). If anyone here would like to let oss-sec know I agree with their assessment I would be grateful.