Fedora has issued an advisory on December 19: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/ZDHLHZ5V5K5AKBTGPLGFTPK3YNSOC4FY/ The issue is fixed upstream in 2.7.5. Mageia 6 may also be affected.
Summary: ansible new security issue => ansible new security issue CVE-2018-16876
Assigning to the registered maintainer.
CC: (none) => marja11Assignee: bugsquad => bruno
ansible-2.7.5-1.mga7 uploaded for Cauldron by Bruno.
Version: Cauldron => 6
ansible-2.4.6.0-1.2.mga6 uploaded by Bruno for Mageia 6 to fix this.
Advisory: ======================== Updated ansible package fixes security vulnerability: It was found that when a retry task in ansible run with -vvv fails, it will log the raw return code, stdout and stderr from ssh which could have contained sensitive data (CVE-2018-16876). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16876 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/ZDHLHZ5V5K5AKBTGPLGFTPK3YNSOC4FY/ ======================== Updated packages in core/updates_testing: ======================== ansible-2.4.6.0-1.2.mga6 from ansible-2.4.6.0-1.2.mga6.src.rpm
Assignee: bruno => qa-bugsCC: (none) => bruno
Mageia 6, x86_64 Updated ansible, which was already working fine. $ ansible all -a "/bin/echo hello" 192.168.1.aaa | UNREACHABLE! => { "changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host 192.168.1.aaa port 22: No route to host\r\n", "unreachable": true } 192.168.1.bbb | SUCCESS | rc=0 >> hello This was expected because host aaa was switched off. --------------------------------------------------------------------------- $ ansible all -a "/home/lcl/bin/calco" 192.168.1.aaa | UNREACHABLE! => { "changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host 192.168.1.aaa port 22: No route to host\r\n", "unreachable": true } 192.168.1.bbb | SUCCESS | rc=0 >> Expected behaviour, as before. A graphical application launched on the local machine. The interactive gui worked fine. --------------------------------------------------------------------------- Booted machine aaa. $ ansible all -a "/bin/echo hello" 192.168.1.aaa | SUCCESS | rc=0 >> hello 192.168.1.bbb | SUCCESS | rc=0 >> hello Good. Authentication was required for the newly booted host aaa. --------------------------------------------------------------------------- $ ansible all -a "/home/lcl/bin/calco" 192.168.1.aaa | FAILED | rc=-6 >> #<Thread:0x00000000015a86c8@/usr/share/gems/gems/tk-0.2.0/lib/tk.rb:1243 run> terminated with exception (report_on_exception is true): /usr/share/gems/gems/tk-0.2.0/lib/tk.rb:32:in `initialize': tcltklib: fail to Tk_Init(). no display name and no $DISPLAY environment variable (RuntimeError) from /usr/share/gems/gems/tk-0.2.0/lib/tk.rb:32:in `initialize' from /usr/share/gems/gems/tk-0.2.0/lib/tk.rb:1246:in `new' from /usr/share/gems/gems/tk-0.2.0/lib/tk.rb:1246:in `block in <module:TkCore>' /usr/share/gems/gems/tk-0.2.0/lib/tk.rb:32:in `initialize': tcltklib: fail to Tk_Init(). no display name and no $DISPLAY environment variable (RuntimeError) from /usr/share/gems/gems/tk-0.2.0/lib/tk.rb:32:in `initialize' from /usr/share/gems/gems/tk-0.2.0/lib/tk.rb:1246:in `new' from /usr/share/gems/gems/tk-0.2.0/lib/tk.rb:1246:in `block in <module:TkCore>' Tcl_AsyncDelete: async handler deleted by the wrong threadnon-zero return code 192.168.1.bbb | SUCCESS | rc=0 >> This is not unexpected - contention for X resources probably - maybe needs more sophisticated programming. --------------------------------------------------------------------------- Added another local machine to /etc/ansible/hosts and modified authorized_keys on the remote host. Treading in Herman's footsteps (bug 23321). $ ansible all -a "/bin/echo hello" 192.168.1.ccc | UNREACHABLE! => { "changed": false, "msg": "Failed to connect to the host via ssh: Permission denied (publickey,password,keyboard-interactive).\r\n", "unreachable": true } 192.168.1.aaa | SUCCESS | rc=0 >> hello 192.168.1.bbb | SUCCESS | rc=0 >> hello Also, the ping test failed: $ ansible -v -i /tmp/hosts all -m ping Using /etc/ansible/ansible.cfg as config file [WARNING]: * Failed to parse /tmp/hosts with yaml plugin: Syntax Error while loading YAML. The error appears to have been in '/tmp/hosts': line 2, column 14, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: 192.168.1.aaa: | SUCCESS => { "changed": false, ^ here exception type: <class 'yaml.scanner.ScannerError'> exception: mapping values are not allowed in this context in "<unicode string>", line 2, column 14 [WARNING]: * Failed to parse /tmp/hosts with ini plugin: /tmp/hosts:1: Expected key=value host variable assignment, got: | [WARNING]: Unable to parse /tmp/hosts as an inventory source [WARNING]: No inventory was parsed, only implicit localhost is available [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all' Don't know what to make of this. Some bits work as expected but others do not.
CC: (none) => tarazed25
MGA6-32 MATE on IBM Thinkpad R50e No installation issues, updating existing ansible Testing to Len's and my own tests, I'm still not with it. At CLI after adding 192.168.2.1 to /tmp/hosts and /etc/ansible/hosts created new key pair and ssh-copy to 192.168.2.1 $ ssh herman@192.168.2.1 Last login: Mon Jan 7 16:03:51 2019 from 192.168.2.6 [herman@mach1 ~]$ pwd /home/herman [herman@mach1 ~]$ exit logout So key pair should be OK. $ ansible -vvvv -u herman -i /tmp/hosts all -m ping loads of verbose explanation, and then 192.168.2.1 | SUCCESS => { "changed": false, "failed": false, "invocation": { "module_args": { "data": "pong" } }, "ping": "pong" } Fine, but then $ ansible all -a "/bin/echo hello" 192.168.2.1 | UNREACHABLE! => { "changed": false, "msg": "Failed to connect to the host via ssh: Permission denied (publickey,password,keyboard-interactive).\r\n", "unreachable": true } So tried $ ansible all -u herman -a "/bin/echo hello" 192.168.2.1 | SUCCESS | rc=0 >> hello and that looks a lot better So for me OK.
Whiteboard: (none) => MGA6-32-OKCC: (none) => herman.viaene
(In reply to Len Lawrence from comment #5) > Don't know what to make of this. Some bits work as expected but others do > not. Are you able to say whether the things that do not work now used to before the update? i.e. do we have regression? I hold the advisory in case.
CC: (none) => lewyssmith
@Lewis, re comment 7. I cannot say for certain that things worked perfectly before the update because I did not make a record of what I did. Some simple tests maybe just to get in the groove. It is much more likely that the failures after the update were caused by user ignorance or some fault in procedure, like setting up SSH for a particular host. A re-run of one of the tests just now showed some improvement just by the addition of an extra command-line parameter (thanks Herman). $ ansible -v -u lcl -i /tmp/hosts all -m ping Using /etc/ansible/ansible.cfg as config file 192.168.1.123 | SUCCESS => { "changed": false, "failed": false, "ping": "pong" } 192.168.1.62 | SUCCESS => { "changed": false, "failed": false, "ping": "pong" } So, no, there is no obvious regression. Thanks Lewis.
Thanks yet again to you both. Sending this on its way.
Whiteboard: MGA6-32-OK => MGA6-32-OK MGA6-64-OKKeywords: (none) => advisory, validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0023.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED