Summary: | <app-admin/ansible-{2.1.4.0_rc3,2.2.1.0_rc5}: Command execution on Ansible controller from host | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | dwfreed <dwfreed> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | calchan, chainsaw, hydrapolic, ikelos, mgorny |
Priority: | Normal | Flags: | stable-bot:
sanity-check+
|
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://www.computest.nl/advisories/CT-2017-0109_Ansible.txt | ||
Whiteboard: | B2 [glsa cve] | ||
Package list: |
=app-admin/ansible-2.1.4.0
=app-admin/ansible-2.2.1.0
|
Runtime testing required: | --- |
Description
dwfreed
2017-01-11 04:41:19 UTC
Does this issue exist in ansible 1.9.*? Couldn't tell you. Somebody just linked me the advisory, and I noticed we were missing the corresponding bug, so I opened it. (In reply to Matthew Thode ( prometheanfire ) from comment #1) > Does this issue exist in ansible 1.9.*? No. Fixing commit is https://github.com/ansible/ansible/commit/ec84ff6de6eca9224bf3f22b752bb8da806611ed ... the playbook/conditional functionality was added in 2.x like the action plugin. (In reply to Thomas Deutschmann from comment #3) > (In reply to Matthew Thode ( prometheanfire ) from comment #1) > > Does this issue exist in ansible 1.9.*? > > No. Fixing commit is > https://github.com/ansible/ansible/commit/ > ec84ff6de6eca9224bf3f22b752bb8da806611ed ... the playbook/conditional > functionality was added in 2.x like the action plugin. I think 1.9.4 is vulnerable (see sample playbook, custom module, and output below). The patched code was indeed introduced in 2.x, but that was a major refactoring effort and similar code/functionality existed in 1.9 as well. Or am I missing something here? --- test.yml ---------------------------- - hosts: localhost tasks: - debug: var=ansible_connection - fact_test: value=foo - debug: var=ansible_connection --- library/test_fact ------------------- #!/usr/bin/python def main(): module = AnsibleModule(argument_spec=dict(value=dict())) ansible_facts=dict(ansible_connection=module.params['value']) module.exit_json(changed=False, ansible_facts=ansible_facts) # import module snippets from ansible.module_utils.basic import * main() --- ansible-playbook test.yml ----------- PLAY [localhost] ************************************************************** GATHERING FACTS *************************************************************** ok: [localhost] localhost TASK: [debug var=ansible_connection] ****************************************** ok: [localhost] => { "var": { "ansible_connection": "local" } } localhost => { var: { ansible_connection: local } } TASK: [fact_test value=foo] *************************************************** ok: [localhost] localhost TASK: [debug var=ansible_connection] ****************************************** fatal: [localhost] => unsupported connection type: foo localhost => { msg: unsupported connection type: foo } PLAY RECAP ******************************************************************** to retry, use: --limit @/home/thiemann/test.retry localhost : ok=3 changed=0 unreachable=1 failed=0 no, looks like you're right :| Matthew, Feel free to fix that as soon as a fix exists. I'm having trouble signing my commits lately and haven't had time to investigate it. Denis. (In reply to Christian Thiemann from comment #4) > (In reply to Thomas Deutschmann from comment #3) > > (In reply to Matthew Thode ( prometheanfire ) from comment #1) > > > Does this issue exist in ansible 1.9.*? > > > > No. Fixing commit is > > https://github.com/ansible/ansible/commit/ > > ec84ff6de6eca9224bf3f22b752bb8da806611ed ... the playbook/conditional > > functionality was added in 2.x like the action plugin. > > I think 1.9.4 is vulnerable (see sample playbook, custom module, and output > below). The patched code was indeed introduced in 2.x, but that was a major > refactoring effort and similar code/functionality existed in 1.9 as well. Or > am I missing something here? > > [...] No, you are right. We contacted upstream and Ansible confirmed that v1.9.x and 2.0.x is affected. However, upstream will _not_ fix 1.9.x and 2.0.x due to the massive refactoring requirement. Users will have to move to 2.1.x or 2.2.x. Given that Gentoo is already on 2.2.x branch I expect that we will wait for a new 2.2.x release or patch our version and cleanup older branches. But that's up to our maintainer(s) ... There are currently 2 new rc4's released 2 days ago (Jan. 11) and rc3's 2 days before that. Both rc3 and rc4 have addition fixes for the cve. 2.1.4.0-0.4rc4 and 2.2.1.0-0.4rc4 If you guys want, I can add them to the tree for your testing. I don't know if they have found any more areas that still need fixing or not. MY mistake in my last comment, latest 2.1.4.0 release is rc2. anisible-2.1.4.0_rc2 and ansible-2.2.1.0_rc4 have been added to the tree unmasked. They contain the latest security fixes for this CVE. And no sooner did I add them, they bumped the rc's again with additional secruity fixes. Now 2.1.4.0_rc3 and 2.2.1.0_rc5 are in the tree. @ Maintainer(s): Thank you for your bump! Upstream has scheduled final release for Monday. Do we want to wait for that version or stabilize the rc? personally I'd rather stabilize a non-rc So let's do it. Shouldn't be a problem do stabilize final versions afterwards (only amd64/x86). @ Arches, please test and mark stable: =app-admin/ansible-2.1.4.0_rc3 =app-admin/ansible-2.2.1.0_rc5 Missed the "non", so let's wait. Yeah, it is better to wait for the finals on Monday... it's only a couple more days. OK, 2.1.4.0 and 2.2.1.0 final releases are pushed to the tree. @ Arches, please test and mark stable: =app-admin/ansible-2.1.4.0 =app-admin/ansible-2.2.1.0 @ Brian: Title was correct. The _rc versions were the first versions available in Gentoo repository containing the fixes for the reported vulnerability. (In reply to Thomas Deutschmann from comment #7) > (In reply to Christian Thiemann from comment #4) > > (In reply to Thomas Deutschmann from comment #3) > > > (In reply to Matthew Thode ( prometheanfire ) from comment #1) > > > > Does this issue exist in ansible 1.9.*? > > > > > > No. Fixing commit is > > > https://github.com/ansible/ansible/commit/ > > > ec84ff6de6eca9224bf3f22b752bb8da806611ed ... the playbook/conditional > > > functionality was added in 2.x like the action plugin. > > > > I think 1.9.4 is vulnerable (see sample playbook, custom module, and output > > below). The patched code was indeed introduced in 2.x, but that was a major > > refactoring effort and similar code/functionality existed in 1.9 as well. Or > > am I missing something here? > > > > [...] > > No, you are right. We contacted upstream and Ansible confirmed that v1.9.x > and 2.0.x is affected. However, upstream will _not_ fix 1.9.x and 2.0.x due > to the massive refactoring requirement. > > Users will have to move to 2.1.x or 2.2.x. > > > Given that Gentoo is already on 2.2.x branch I expect that we will wait for > a new 2.2.x release or patch our version and cleanup older branches. But > that's up to our maintainer(s) ... Thanks for confirming with upstream as well! For what it's worth, patching 1.9 probably wouldn't be too hard: the function _save_play_facts in lib/ansible/playbook/__init__.py line 516 is responsible for processing "ansible_facts" returned in module results. If you remove critical keys like "ansible_connection", "ansible_become", and "ansible_python_interpreter" from the "facts" dict before it's passed into "utils.update_hash(...)", you'll probably be good. That being said, I've (finally) made the switch to Ansible 2.x, so I haven't tested this myself and don't know if it would be a comprehensible fix. New GLSA request filed. amd64 stable x86 stable. Maintainer(s), please cleanup. @ Maintainer(s): Please cleanup and drop <app-admin/ansible-2.1.4.0 and <app-admin/ansible-2.2.1.0. This issue was resolved and addressed in GLSA 201701-77 at https://security.gentoo.org/glsa/201701-77 by GLSA coordinator Thomas Deutschmann (whissi). Re-opening for cleanup. cleaned up @ Maintainer(s): Thank you! All done, repository is clean. |