Fedora has issued an advisory on March 15: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/FWDK3QUVBULS3Q3PQTGEKUQYPSNOU5M3/ The issues are fixed upstream in 2.7.17 and 2.9.6. Mageia 7 is also affected.
Status comment: (none) => Fixed upstream in 2.7.17 and 2.9.6Whiteboard: (none) => MGA7TOO
cauldron updated with 2.9.6
Version: Cauldron => 7Status: NEW => ASSIGNED
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.
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
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.
I don't see an update in Cauldron. Did you forget to mgarepo submit?
Oops right sorry. Done now.
Whiteboard: MGA7TOO => (none)Status comment: Fixed upstream in 2.7.17 and 2.9.6 => Fixed upstream in 2.7.17Version: Cauldron => 7
RedHat has issued advisories on April 22: https://access.redhat.com/errata/RHSA-2020:1542 https://access.redhat.com/errata/RHSA-2020:1544 The issues are fixed upstream in 2.7.17 and 2.9.7: https://github.com/ansible/ansible/blob/v2.7.17/changelogs/CHANGELOG-v2.7.rst https://github.com/ansible/ansible/blob/v2.9.7/changelogs/CHANGELOG-v2.9.rst 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-10691Whiteboard: (none) => MGA7TOOVersion: 7 => CauldronStatus comment: Fixed upstream in 2.7.17 => Fixed upstream in 2.7.17 and 2.9.7Source 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
Fedora has issued an advisory for this today (April 27): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/DKPA4KC3OJSUFASUYMG66HKJE7ADNGFW/
RedHat has issued an advisory for CVE-2020-1753 today (May 13): https://access.redhat.com/errata/RHSA-2020:2142 Now they say it's actually fixed in 2.7.18. 2.9.9 is out as well: https://access.redhat.com/errata/RHBA-2020:2139
Status comment: Fixed upstream in 2.7.17 and 2.9.7 => Fixed upstream in 2.7.18 and 2.9.7
2.9.9 pushed to cauldron and 2.7.18 to mga7 update_testing
Assignee: bruno => qa-bugs
Advisory: ======================== 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 (CVE-2020-1737). 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). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1733 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1735 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1737 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1739 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1740 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1746 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1753 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10684 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10685 https://github.com/ansible/ansible/blob/v2.7.17/changelogs/CHANGELOG-v2.7.rst https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/FWDK3QUVBULS3Q3PQTGEKUQYPSNOU5M3/ https://access.redhat.com/errata/RHSA-2020:1544 https://access.redhat.com/errata/RHSA-2020:2142
Whiteboard: MGA7TOO => (none)Version: Cauldron => 7CC: (none) => brunoStatus comment: Fixed upstream in 2.7.18 and 2.9.7 => (none)
Updated packages in core/updates_testing: ======================== ansible-2.7.18-1.mga7 from ansible-2.7.18-1.mga7.src.rpm
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: 127.0.0.1 | 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: 127.0.0.1 | UNREACHABLE! => { ............ 192.168.1.62 | CHANGED | rc=0 >> 192.168.1.70 | 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: 127.0.0.1 | 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-OKCC: (none) => tarazed25
Validating. Advisory in Comment 11.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => advisoryCC: (none) => tmb
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0217.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED
*** Bug 27724 has been marked as a duplicate of this bug. ***
CC: (none) => zombie_ryushu