Thanks reporting this,

Assigning to current registered packager.

CC: (none) => ouaurelien
Assignee: bugsquad => bruno.cornec

Fixed in ansible-2.9.12-1.mga8 in Cauldron by Guillaume.

Whiteboard: MGA7TOO => (none)
CC: (none) => guillomovitch
Version: Cauldron => 7

THere is no backport for the 2.7 ansible version we have in mga7. Should I move also to 2.9 there, or should I try to create a backport myself ?

CC: (none) => bruno
Status: NEW => ASSIGNED

Backport the patches if possible, otherwise we can update it. (2.8.14 probably has the fixes too)

If I can't backport to the 2.7 I'd prefer to align to 2.9 rather than pushing 2.8.
Working on it today.

From https://github.com/ansible/ansible/issues/67794 it seems I'll have to wait a bit (up to 1st of ept it seems)

From what I found looking at the issue:

For CVE-14330 the right commit is https://github.com/ansible/ansible/commit/e0f25a2b1f9e6c21f751ba0ed2dc2eee2152983e
For CVE-14332 the right commit is https://github.com/ansible/ansible/pull/71033/commits/c6da98b61948c41a7c171d0ba5cad1d001c3ba0b
For CVE-2020-1736 the bug is still open upstream (https://github.com/ansible/ansible/issues/67794)

I've rebuild a version 2.7.18-1.1 with the 2 above patches. I can aloready push that to updates_testing if you think it's useful. Or we can wait till we have a final patch upstream for the last CVE.

Yeah I think it's ok to wait.  Sounds like they'll have it fixed this week.

RedHat has issued advisories today (September 1):
https://access.redhat.com/errata/RHSA-2020:3600
https://access.redhat.com/errata/RHSA-2020:3602

The new issue is fixed upstream in 2.8.15 and 2.9.13.

Version: 7 => Cauldron
Whiteboard: (none) => MGA7TOO
Summary: ansible new security issues CVE-2020-1736 and CVE-2020-1433[02] => ansible new security issues CVE-2020-1736, CVE-2020-1433[02], CVE-2020-14365

2.9.13 uploaded to cauldron.

ansible-2.9.13-1.mga8 uploaded by Bruno, thanks.

I assume they've worked out the issues with CVE-2020-1736 now.

Whiteboard: MGA7TOO => (none)
Version: Cauldron => 7

Seems CVE-2020-1736 is still open (bug report is not closed yet)

But I'm unsure whether 2.7 is affected, as the change was related to evolutions during 2.8.

From the last patch:

+* Version 2.8.14 of Ansible changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the ``mode`` change has been reverted in 2.8.15, and ``mode`` will now default to ``0o666 & ~umask`` as in previous versions of Ansible.
+* If you changed any tasks to specify less restrictive permissions while using 2.8.14, those changes will be unnecessary (but will do no harm) in 2.8.15.
+* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it.

(commit 69827e089415a9d3f9e6b538f8ad64fbb2e079ce)

So I *think* our version is not touched by that. 
Added also the fix for CVE-2020-14365 and pushing to updates_testing

No, I'm pretty sure 2.7 is affected.  2.8.14 is where they attempted to fix it, but they reverted the fix.

So we don't have a fix for CVE-2020-1736 right now, but it sounds like not a big deal.  0666 ~ umask is what the OS does anyway, so that should be fine.

Advisory:
========================

Updated ansible package fixes security vulnerabilities:

An Improper Output Neutralization for Logs flaw was found in Ansible when using
the uri module, where sensitive data is exposed to content and json output.
This flaw allows an attacker to access the logs or outputs of performed tasks
to read keys used in playbooks from other users within the uri module. The
highest threat from this vulnerability is to data confidentiality
(CVE-2020-14430).

A flaw was found in the Ansible Engine when using module_args. Tasks executed
with check mode (--check-mode) do not properly neutralize sensitive data
exposed in the event data. This flaw allows unauthorized users to read this
data. The highest threat from this vulnerability is to confidentiality
(CVE-2020-14432).

A flaw was found in the Ansible Engine when installing packages using the dnf
module. GPG signatures are ignored during installation even when
disable_gpg_check is set to False, which is the default behavior. This flaw
leads to malicious packages being installed on the system and arbitrary code
executed via package installation scripts. The highest threat from this
vulnerability is to integrity and system availability (CVE-2020-14365).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14330
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14332
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14365
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/2NYYQP2XJB2TTRP6AKWVMBSPB2DFJNKD/
https://access.redhat.com/errata/RHSA-2020:3600
========================

Updated packages in core/updates_testing:
========================
ansible-2.7.18-1.1.mga7

from ansible-2.7.18-1.1.mga7.src.rpm

Assignee: bruno.cornec => qa-bugs

MGA7-64 Plasma on Lenovo B50
No installation issues, draws in some other 18 packages.
Following bug 26349, created a hosts file, but
$ ansible -k -i /tmp/hosts all -m ping
SSH password: 
localhost | FAILED! => {
    "msg": "to use the 'ssh' connection type with passwords, you must install the sshpass program"
}
192.168.2.5 | FAILED! => {
    "msg": "to use the 'ssh' connection type with passwords, you must install the sshpass program"
}
192.168.2.1 | FAILED! => {
    "msg": "to use the 'ssh' connection type with passwords, you must install the sshpass program"
Up to now not in the clear what this sshpass program really is. Missing dependency?

CC: (none) => herman.viaene

It's not a hard dependency.  It depends on how you use it.  People usually use ssh keys with Ansible.  Otherwise you have to use sshpass so it can provide passwords non-interactively.

Problem was at the time of my first test, I did not find sshpass. Today when using urpmf I find it,and installed it. Strange to me:it is listed in the update repos, not in the core.
Anyway, still struggling what should go in that hosts file.
I put in it three IP adresses, and one FQDN all four of them with an ansible_user and ansible_password defined.
When using the command
$ ansible -k -i /tmp/hosts all -m ping
I get for the two addresses for this laptop "Connection refused" using the actual user/password I'm logged in with, for my desktop PC I get "Success" for the FQDN and "Connection timed out" for its LAN-IP-address, both having the same ansible_user and ansible_password.

This is mind boggling for me.

That does sound mind boggling.  I feel silly asking, as I believe Mageia runs sshd and has that open in the firewall by default, but perhaps it's still worth checking that both are the case for the computers it refuses to connect to (also that you can regular ping them, just to rule out any other issues).

Ping commands all OK. Tried ssh from the command line, and then I got it: if I want to ssh into the laptop itself, it needs to run sshd. Which I never installed on this laptop before since I rre-installed it a few months ago.
Once that is mended and the user and passwords are OK in the hosts file, I get 5 times success. One on 127.0.0.1, and on the LAN-IP-addresses and the FQDN of the laptop and desktop in the LAN.

For future reference:
the hosts file contains lines like
<ident of machine> ansible_user=<usename> ansible_pssword=<password of the user>

and at the CLI:
$ ansible -k -i ~/tmp/hosts all -m ping
SSH password: 
leave that paswword empty.

Finally OK.

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

Thanks David, I was AFAK and you hit the "advisory button" before me.
I shoulda do it as soon as do svn.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2020-0363.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED