Ansible 1.5.1 released: security updates

Ansible 1.5.1 Release Notes

Today we’re releasing Ansible 1.5.1 which contains three security fixes/upgrades as well as a few assorted bugfixes that have been applied since the 1.5 release. An upgrade is suggested for all users using vault, interacting with web-properties over https://, or those users allowing outside untrusted input to be passed as variables to their ansible playbooks.

The security improvements are as follows:

Ansible Vault has been updated in terms of how the cipher logic has been implemented to make the content harder to brute force. Using the “edit” or “rekey” functions in vault will automatically upgrade an existing vault-encrypted file to the new format, and the new format is also the method used for any new files that vault creates. Users are encouraged to upgrade their content as follows, and should also consider changing any passwords or keys in vault-encrypted files to take advantage of security upgrades, as the previous versions would still exist in SCM history or may have been copied by another party.

cd your_playbook_directory/

find . -type f | xargs grep -l ‘$ANSIBLE_VAULT;1.0;AES’ | xargs ansible-vault rekey

Note that the version of pycrypto Vault now needs is newer than what is carried in the base channel of Red Hat and CentOS, so if you are using this distribution you may benefit from:

yum install python-devel

rpm -e --nodeps python-crypto

pip install pycrypto

If you have a downlevel version the system will warn you about this. If you are using vault, you need not worry about this dependency.

Core ansible modules (other than the shell module) have been upgraded to avoid running user input through the shell. Some ansible users have proxied ansible behind a wrapper script or web proxy (including Ansible Tower), that allows users who do not personally have access to machines to be able to supply variables as input into playbook executions. This includes doing things such as providing a value to “–extra-args” that might contain a semicolon, allowing them to run commands as a remote user. Removing the ability to use the shell in all of these modules prevents command injection in this case. The shell module by design executes commands through the shell, so if user supplied variables are being fed to things executed by the shell module, consider using the “command” module instead or whether users supplying input are trustworthy. User developed modules can take advantage of these upgrades by using the “run_command” function in “module_utils”, which will by default not allow any form of shell usage, which is now standard and required for all ansible modules in core. Regardless of this fix application, users of ansible should realize that any user that is allowed to write playbooks can control the systems upon which the playbooks are applied, which is intentional and by design.

Finally, code that performs URL downloads of https:// URLs has been upgraded to validate the certificates where possible, unless a new parameter “validate_certs=no” is passed to the module. This ensures that web servers that are interacted with are signed by a known certificate authority. It is very likely that this may require playbook alteration to add a “validate_certs=no” to any modules like “get_url” that interact with self-signed web services, such as continuous integration servers. In the event that this should occur, the playbook will report an appropriate error message and reference the ability to add “validate_certs=no” to get around the error message.

Ansible 1.5.1 is available now on http://releases.ansible.com as well as the python package index, via “pip install ansible”. It is anticipated that distribution copies of the package, as well as other repositories, will pick this up soon.

I see 1.5.2 in github too

Hi

On the release dir, the new file reads:

ansible-1.6.tar.gz 10-Mar-2014 23:13 532K

I’m guessing this is a typo??

1.6 is the current development branch

The 1.5.2 branch is for staging future dot releases, should we decide to produce a dot release.

In particular we noted one problem with the airbrake module, so it lives there.

It’s not actively released, nor tagged, at this point.

The 1.5.1 tarball is there as well.

The 1.6 tarball there is not a release tarball, and is a build system artifact that is a result of our CI and probably a wrong button press. I’ll have someone delete that shortly.

Download the 1.5.1 tarball.

Hello everyone, we have updated 1.5.1 with a 1.5.2 to fix a bug in the apt module as a result of the above.

Please apply 1.5.2 instead.

It should be available now and if we need to update any other modules, we will do so quickly.

Thanks to everyone who reported things!

completely missed that.
thanks!

Missed a cherry-pick on 1.5.2

The 1.5.2 tarball has been updated and the tag has been moved.

PyPi has been updated.

Hello,

Are there any plans to give users the option of re-enabling execution via shell (for the pipe lookup module in particular) or is it to be considered “officially wrong” from now on? We’re using something like:
macro_new_pass32: “{{ lookup(‘pipe’,‘cat /dev/urandom | tr -dc A-Za-z0-9 | head -c32’) }}”
to generate temporary throw away passwords without putting them into a file on the local machine (like the password lookup) which this change breaks.

the lookup runs on the control machine, it is not passed to the target, only it’s result.

If the pipe filter is not working in a way that it previously worked, please file a bug and we will look into it.

This code is also used in side modules, like the Flowdoc notification module where I get :
msg: failed to validate the SSL certificate for api.flowdock.com:443. You can use validate_certs=no, however this is unsafe and not recommended

Adding the “validate_certs=no” option to this module only return a : “msg: unsupported parameter for module: validate_certs”

The validate_certs thing is different from the shell stuff.

We are currently working on some fixes for places that needed to have shell access (small number, but facts are included for non-Linux for example, and some git usage) and also are upgrading the cert detection.

Should have a release soon-ish, so stay tuned.

(The pipes stuff won’t need to request shell as it’s already executed with hit. if this is concerning, don’t include with_pipe in the playbooks, etc)

I’m doing this:

which worked fine with 1.5 - but with 1.5.2 from PyPi, I now get this:

failed: [default] => {“failed”: true, “item”: “”}
msg: failed to validate the SSL certificate for protobuf.googlecode.com:443. You can use validate_certs=no, however this is unsafe and not recommended

FATAL: all hosts have already failed – aborting

Adding validate_certs=no to the get_url fixes this, but it’s Google Code and seems to have a valid cert - according to my browsers - any idea why ansible doesn’t like it?

I’m also getting this with bitbucket.

1.5.3 is in PyPi now and this contains some improvements to check additional files and locations, let us know if you are still seeing any problems.

(Ubuntu users may also wish to run update-ca-certs to get the latest files)

–Michael

Ansible 1.5.3 fixes this, thanks!