Bug 24065 - ansible new security issue CVE-2018-16876
Summary: ansible new security issue CVE-2018-16876
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA6-32-OK MGA6-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2018-12-25 21:40 CET by David Walser
Modified: 2019-01-08 22:51 CET (History)
6 users (show)

See Also:
Source RPM: ansible-2.7.0-3.mga7.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2018-12-25 21:40:17 CET
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.
David Walser 2018-12-26 03:27:58 CET

Summary: ansible new security issue => ansible new security issue CVE-2018-16876

Comment 1 Marja Van Waes 2018-12-26 07:56:19 CET
Assigning to the registered maintainer.

CC: (none) => marja11
Assignee: bugsquad => bruno

Comment 2 David Walser 2018-12-29 20:15:00 CET
ansible-2.7.5-1.mga7 uploaded for Cauldron by Bruno.

Version: Cauldron => 6

Comment 3 David Walser 2018-12-29 20:18:34 CET
ansible-2.4.6.0-1.2.mga6 uploaded by Bruno for Mageia 6 to fix this.
Comment 4 David Walser 2018-12-29 20:59:25 CET
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-bugs
CC: (none) => bruno

Comment 5 Len Lawrence 2018-12-31 20:09:13 CET
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

Comment 6 Herman Viaene 2019-01-07 16:31:09 CET
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-OK
CC: (none) => herman.viaene

Comment 7 Lewis Smith 2019-01-07 19:12:10 CET
(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

Comment 8 Len Lawrence 2019-01-07 19:50:30 CET
@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.
Comment 9 Lewis Smith 2019-01-07 20:04:43 CET
Thanks yet again to you both. Sending this on its way.

Whiteboard: MGA6-32-OK => MGA6-32-OK MGA6-64-OK
Keywords: (none) => advisory, validated_update
CC: (none) => sysadmin-bugs

Comment 10 Mageia Robot 2019-01-08 22:51:42 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2019-0023.html

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


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