Command execution on Ansible controller from host

https://www.computest.nl/advisories/CT-2017-0109_Ansible.txt

by robin_reala • 10 years ago

112 54 10 years ago

computest.nl

ivank• 10 years ago

https://www.computest.nl/advisories/CT-2017-0109_Ansible.txt has the bug details

Edit: LWN link was changed to this one

witty_username• 10 years ago

Can mods change the link to this?

wvh• 10 years ago

Thanks! Some of those are somewhat embarrassing, especially for something that's meant to be software used in secure environments. Why does a client need to specify an interpreter to run on the master host? Or changing the template brackets to escape quoting? I'm also thinking that maybe Python might be a bit too dynamic – allowing anything by design – bringing its own share of problems to developing security-conscious software.

icebraining2• 10 years ago

Why does a client need to specify an interpreter to run on the master host?

No, the client specifies the interpreter to use inside itself.

sirn• 10 years ago

Why does a client need to specify an interpreter to run on the master host?

Some system have Python installed in a rather uncommon location. For example, Python is not part of FreeBSD base system, so Python is installed at /usr/local/bin/python instead of the expected /usr/bin/python, or Arch has Python 2 installed at /usr/bin/python2 rather than /usr/bin/python.

Note that Ansible doesn't require itself to be installed on the remote host (and IMHO is one of its biggest selling point) and execute tasks by sending a packed version of a task to the remote host and execute it using `ansible_python_interpreter` (e.g. `/usr/bin/python /tmp/ansible-tmp-a43bf412.py`)

cperciva2• 10 years ago

If only we had some form of superluminal communication, it might be possible to patch all the affected systems before they get exploited.

vog5• 10 years ago

Not sure what you are trying to say. Are you trying say that the CVS publication happened too early? If so, the timeline tells a different story:

    2016-12-08	First contact with Ansible security team
    2016-12-09	First contact with Redhat security team (secalert@redhat.com)
    2016-12-09	Submitted PoC and description to security@ansible.com
    2016-12-13	Ansible confirms issue and severity
    2016-12-15	Ansible informs us of intent to disclose after holidays
    2017-01-05	Ansible informs us of disclosure date and fix versions
    2017-01-09	Ansible issues fixed version

cperciva2• 10 years ago

It was a joke about the name: https://en.wikipedia.org/wiki/Ansible

(Well, that plus the fact that this seems like the sort of scary bug which will get exploited very quickly.)

romanr• 10 years ago

Can anyone explain in simple terms what is this about? Exploit found in Ansible? Should we all update asap?

I couldn't understand from article or discussion.

grey-area• 10 years ago

Ansible sends commands to servers, but asks them for certain data first (facts).

If one of your servers is compromised, this is a vulnerability in the ansible client that lets that bad server take over your local computer and your other servers when you connect to it by sending you bad facts.

So it's pretty serious.

mverwijs• 10 years ago

Puppet uses facter and chef ohai to achieve te same thing. Could they be exploited in similar fashion?

Piatro• 10 years ago

Unfortunately versions 2.1.4 and 2.2.1 are still in release candidate phase so package managers such as Homebrew are still using vulnerable releases, as far as I can tell.

jorrizza• 10 years ago

The fixed version does not seem to be released yet on pypi or their launchpad PPA. The only (official) place where a fixed release is available seems to be https://releases.ansible.com/ansible/

estefan3• 10 years ago

Am I the only one who finds it pretty unprofessional to release the exploits when the fixed version hasn't been released yet (and anyway was only scheduled to have been released 48 hours beforehand)?

I'm all for disclosure, but seriously - if RH want Ansible to be used in enterprise they can't expect patches at this rate. The researchers releasing the exact exploits so quickly is just irresponsible IMO.

knocte• 10 years ago

But to be a victim of this vulnerability you need to have one of the hosts already compromised AFAIU, so I don't think it's that severe.

brianwawok• 10 years ago

Any exploit that turns a 1 host hack into hack entire data enter with root access seems worth a patch....

tptacek• 10 years ago

No, you're not the only one, but this is one of the oldest debates in computer security --- possibly the oldest debate --- and at least as many people as agree with you vigorously disagree and think that delaying information to conform with enterprise patch cycles does harm to organizations with strong security teams who can handle and respond to reports like this; those organizations tend to be the ones with the most users and the most sensitive data to protect.

While I sympathize far more with the full disclosure people than with the patch choreography people, I'm really only pointing this out to demonstrate that you're not going to resolve this debate in the HN comments about an Ansible vulnerability.

emmelaich• 10 years ago

The article says fixes have been released.

Resolution ---------- Ansible has released new versions that fix the vulnerabilities described in this advisory: version 2.1.4 for the 2.1 branch and 2.2.1 for the 2.2 branch.

estefan3• 10 years ago

The article is wrong. Pypi only shows 2.2.0 released in November. That's my point.

ensignavenger2• 10 years ago

I'm just starting to use Ansible for a major deployment at work, so I am not an expert- can anyone who knows more explain why "ansible_connection" exists as a host definable fact? The controller already knows what host it is connecting to when it retrieves the fact, so why can the host change it?

bcoca4• 10 years ago

it is not a host definable fact, it is a 'host variable' which you normally define in inventory.

ensignavenger2• 10 years ago

From the advisory:

When Ansible runs on a host, a JSON object with Facts is returned to the Controller. The Controller uses these facts for various housekeeping purposes. Some facts have special meaning, like the fact "ansible_python_interpreter" and "ansible_connection".

So while you may normally define it in the inventory, it sounds like, from the advisory, it can also be defined by the host.

mdeeks• 10 years ago

No fix for 1.9? We are stuck on 1.9 because 2.X does not support connecting to more than a couple hundred hosts. This ticket has been open for about a year now: https://github.com/ansible/ansible/issues/14143#issuecomment...

scrollaway• 10 years ago

Have you considered working on it to fix that issue?

bcoca4• 10 years ago

disclaimer: I'm one of the maintainers

I'll try to answer several questions so this might get long.

First, the procedure for disclosing the CVE is something we discussed internally (including security professionals), as all over the internet there are 2 or more views on this. The decision arrived at doesn't please everyone (I doubt one that would exists), but it is a recognized way of dealing with security issues, so it is what we followed.

The CVE can be dense explaining how the exploits work. The simple version: it is a rehash of an old problem which we had thought solved, the researchers proved us wrong by finding ways around our filtering. The vulnerability is pretty hard to trigger and requires both a compromised system to intercept the Ansible calls and return faulty data and intimate knowledge of the existing playbooks and systems used to force the arbitrary execution.

All software has flaws, this is not an excuse, it is a fact. Not all software or flaws have the same scope though. As a automation tool that is often used to manage things with high levels of privilege, we take these things very seriously and we do our best to prevent it in the first place or remediate it as soon as possible. As an OSS project we appreciate the eyes and efforts many put into finding these flaws which end up making the software better (and me a better programmer).

Ansible is not idempotent, it is declarative, which does help the user create idempotent plays. True idempotency depends on many things, the modules used, the problem addressed and how the playbooks are written, etc. Both of the following are valid ansible tasks, but the implications are very different even if the result ends up being the same.

- shell: usermod -G user bcoca

- user: state=present name=bcoca groups=user

I hope this helps,

rarrrrrr• 10 years ago

Odd. I reported this very same form of vulnerability to the Ansible team in the 1.5.4 series in 2014, where the code basically eval'd the "facts" discovered from a system under management.

There was this "safe_eval" function which filtered input in a way quite inconsistent with its name. The Ansible team was responsive and pleasant to work with!

https://groups.google.com/forum/#!topic/ansible-project/MUQx...

But I suspect lots of remote control and monitoring software products might have security bugs like this where they assume that the returned information from systems under management are trustworthy.

Edit to add: Here's the patch made to safe_eval in 2014. I had suggested using literal_eval instead but I guess a Python 2.6+ requirement wouldn't work. https://github.com/ansible/ansible/commit/998793fd0ab55705d5...

Edit again: Ansible is a pretty great product, and IMO one of the first of such tools to seriously improve the UX for sysadmins. Thanks for maintaining it!

Command execution on Ansible controller from host

Related Stories