Bug 26349 - ansible new security issues CVE-2020-173[3579], CVE-2020-174[06], CVE-2020-1753, CVE-2020-1068[45], CVE-2020-10691
Summary: ansible new security issues CVE-2020-173[3579], CVE-2020-174[06], CVE-2020-17...
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA7-64-OK
Keywords: advisory, validated_update
: 27724 (view as bug list)
Depends on:
Reported: 2020-03-16 21:50 CET by David Walser
Modified: 2020-12-04 00:53 CET (History)
6 users (show)

See Also:
Source RPM: ansible-2.9.6-1.mga8.src.rpm, ansible-2.7.16-1.mga7.src.rpm
Status comment:


Description David Walser 2020-03-16 21:50:30 CET
Fedora has issued an advisory on March 15:

The issues are fixed upstream in 2.7.17 and 2.9.6.

Mageia 7 is also affected.
David Walser 2020-03-16 21:51:04 CET

Status comment: (none) => Fixed upstream in 2.7.17 and 2.9.6
Whiteboard: (none) => MGA7TOO

Comment 1 Bruno Cornec 2020-03-17 01:18:48 CET
cauldron updated with 2.9.6

Version: Cauldron => 7

Comment 2 Bruno Cornec 2020-03-17 01:24:09 CET
Hummm seems there is another one: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1733 touching 2.7.17 (not available upstream) and 2.9.6
So will have to way a bit to re-update cauldron and have a version for 7.
Comment 3 David Walser 2020-03-17 15:28:34 CET
They've known about that issue for months and haven't fixed it, so I think we can go ahead and do this update now.

Version: 7 => Cauldron

Comment 4 Bruno Cornec 2020-03-17 19:48:41 CET
I wish I could, but 2.7.17 is NOT available upstream yet. So we need to wait till that happens. And hopefully both issues will be covered.

Now cauldron has a new version, but which also has that other vulnerability.
Comment 5 David Walser 2020-03-17 21:53:30 CET
I don't see an update in Cauldron.  Did you forget to mgarepo submit?
Comment 6 Bruno Cornec 2020-03-18 09:24:40 CET
Oops right sorry. Done now.
David Walser 2020-03-18 11:40:20 CET

Whiteboard: MGA7TOO => (none)
Status comment: Fixed upstream in 2.7.17 and 2.9.6 => Fixed upstream in 2.7.17
Version: Cauldron => 7

Comment 7 David Walser 2020-04-23 20:30:31 CEST
RedHat has issued advisories on April 22:

The issues are fixed upstream in 2.7.17 and 2.9.7:

CVE-2020-10691 does not affect 2.7.x.

Summary: ansible new security issues CVE-2020-1737 and CVE-2020-1739 => ansible new security issues CVE-2020-173[3579], CVE-2020-174[06], CVE-2020-1753, CVE-2020-1068[45], CVE-2020-10691
Whiteboard: (none) => MGA7TOO
Version: 7 => Cauldron
Status comment: Fixed upstream in 2.7.17 => Fixed upstream in 2.7.17 and 2.9.7
Source RPM: ansible-2.9.5-2.mga8.src.rpm => ansible-2.9.6-1.mga8.src.rpm, ansible-2.7.16-1.mga7.src.rpm

Comment 8 David Walser 2020-04-28 03:42:45 CEST
Fedora has issued an advisory for this today (April 27):
Comment 9 David Walser 2020-05-13 19:04:32 CEST
RedHat has issued an advisory for CVE-2020-1753 today (May 13):

Now they say it's actually fixed in 2.7.18.

2.9.9 is out as well:

Status comment: Fixed upstream in 2.7.17 and 2.9.7 => Fixed upstream in 2.7.18 and 2.9.7

Comment 10 Bruno Cornec 2020-05-17 16:59:00 CEST
2.9.9 pushed to cauldron and 2.7.18 to mga7 update_testing

Assignee: bruno => qa-bugs

Comment 11 David Walser 2020-05-17 19:57:00 CEST

Updated ansible package fixes security vulnerabilities:

A race condition flaw was found in Ansible Engine when running a playbook with
an unprivileged become user. When Ansible needs to run a module with become
user, the temporary directory is created in /var/tmp. This directory is
created with "umask 77 && mkdir -p <dir>"; this operation does not fail if the
directory already exists and is owned by another user. An attacker could take
advantage to gain control of the become user as the target directory can be
retrieved by iterating '/proc/<pid>/cmdline' (CVE-2020-1733).

A flaw was found in the Ansible Engine when the fetch module is used. An
attacker could intercept the module, inject a new path, and then choose a new
destination path on the controller node (CVE-2020-1735).

A flaw was found in the Ansible Engine when using the Extract-Zip function from
the win_unzip module as the extracted file(s) are not checked if they belong to
the destination folder. An attacker could take advantage of this flaw by
crafting an archive anywhere in the file system, using a path traversal

A flaw was found in Ansible Engine. When a password is set with the argument
"password" of svn module, it is used on svn command line, disclosing to other
users within the same node. An attacker could take advantage by reading the
cmdline file from that particular PID on the procfs (CVE-2020-1739).

A flaw was found in Ansible Engine when using Ansible Vault for editing
encrypted files. When a user executes "ansible-vault edit", another user on
the same computer can read the old and new secret, as it is created in a
temporary file with mkstemp and the returned file descriptor is closed and the
method write_data is called to write the existing secret in the file. This
method will delete the file before recreating it insecurely (CVE-2020-1740).

A flaw was found in the Ansible Engine when the ldap_attr and ldap_entry
community modules are used. The issue discloses the LDAP bind password to
stdout or a log file if a playbook task is written using the bind_pw in the
parameters field. The highest threat from this vulnerability is data
confidentiality (CVE-2020-1746).

A security flaw was found in the Ansible Engine when managing Kubernetes using
the k8s connection plugin. Sensitive parameters such as passwords and tokens
are passed to the kubectl command line instead of using environment variables
or an input configuration file, which is safer. This flaw discloses passwords
and tokens from the process list, and the no_log directive from the debug
module would not be reflected in the underlying command-line tools options,
displaying passwords and tokens on stdout and log files (CVE-2020-1753).

A flaw was found in the Ansible Engine. When using ansible_facts as a subkey
of itself, and promoting it to a variable when injecting is enabled,
overwriting the ansible_facts after the clean, an attacker could take
advantage of this by altering the ansible_facts leading to privilege
escalation or code injection. The highest threat from this vulnerability are
to data integrity and system availability (CVE-2020-10684).

A flaw was found on Ansible Engine when using modules which decrypts vault
files such as assemble, script, unarchive, win_copy, aws_s3 or copy modules.
The temporary directory is created in /tmp leaves the secrets unencrypted. On
Operating Systems which /tmp is not a tmpfs but part of the root partition,
the directory is only cleared on boot and the decrypted data remains when the
host is switched off. The system will be vulnerable when the system is not
running. So decrypted data must be cleared as soon as possible and the data
which normally is encrypted is sensible (CVE-2020-10685).


Whiteboard: MGA7TOO => (none)
Version: Cauldron => 7
CC: (none) => bruno
Status comment: Fixed upstream in 2.7.18 and 2.9.7 => (none)

Comment 12 David Walser 2020-05-17 19:58:00 CEST
Updated packages in core/updates_testing:

from ansible-2.7.18-1.mga7.src.rpm
Comment 13 Len Lawrence 2020-05-18 14:53:50 CEST
mga7, x86_64

Checked a few of the CVEs but could not see any reproducers.

Created a /tmp/hosts file containing IP addresses for localhost and two local networked machines.
Ran the ping test, which failed on localhost because of SSH problems with the identification - used to that.  OK for the other two.
$ ansible -k -i /tmp/hosts all -m ping
SSH password: | UNREACHABLE! => {
<canopus> | SUCCESS => {
    "changed": false,
    "ping": "pong"
<belexeuli> | SUCCESS => {
    "changed": false,
    "ping": "pong"

Ran an application remotely, with similar results.
$ ansible -k -i /tmp/hosts all -a "/home/lcl/bin/chex"
SSH password: | UNREACHABLE! => {
............ | CHANGED | rc=0 >> | CHANGED | rc=0 >>

The remote desktops each showed a gui which required a response.  When that was given the acknowledgement came back.

$ ansible -k -i ~/tmp/hosts all -a "mate-terminal -e 'inxi -b'"
SSH password: | UNREACHABLE! => {
<belexeuli> | FAILED | rc=255 >>

(mate-terminal:973627): Gtk-WARNING **: 13:48:04.160: Theme parsing error: colors.css:71:44: Invalid number for color value

The Mate terminal appeared briefly on the host machine and displayed inxi output before crashing.  Not at all sure what is going on there but it is the same behaviour as in past tests so is not a regression.  Maybe ansible is not designed for such tests.

The SSH problem is a perennial one which might be solved by getting rid of known_hosts.  It is a bit beyond me.  Otherwise ansible seems to be working.

Whiteboard: (none) => MGA7-64-OK
CC: (none) => tarazed25

Comment 14 Thomas Andrews 2020-05-19 00:28:51 CEST
Validating. Advisory in Comment 11.

Keywords: (none) => validated_update
CC: (none) => andrewsfarm, sysadmin-bugs

Thomas Backlund 2020-05-24 15:55:20 CEST

Keywords: (none) => advisory
CC: (none) => tmb

Comment 15 Mageia Robot 2020-05-24 20:06:25 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Comment 16 David Walser 2020-12-04 00:53:39 CET
*** Bug 27724 has been marked as a duplicate of this bug. ***

CC: (none) => zombie_ryushu

Note You need to log in before you can comment on or make changes to this bug.