Bug 23711

Done for Cauldron and mga6!

CC: (none) => geiger.david68210

(In reply to David GEIGER from comment #1)
> Done for Cauldron and mga6!

You rock, thanks :-)

Assigning to David for the Advisory.

Assignee: bugsquad => luigiwalser
Source RPM: libssh-0.8.3-1.mga7.src.rpm => libssh
CC: (none) => marja11
Whiteboard: MGA6TOO => (none)
Version: Cauldron => 6

Be careful Marja, editing too many Bugzilla fields.

Source RPM: libssh => libssh-0.7.5-1.mga6.src.rpm

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

Updated libssh packages fix security vulnerability:

libssh versions 0.6 and above have an authentication bypass vulnerability in the
server code.  By presenting the server an SSH2_MSG_USERAUTH_SUCCESS message in
place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to
initiate authentication, the attacker could successfully authentciate without
any credentials (CVE-2018-10933).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10933
https://www.libssh.org/security/advisories/CVE-2018-10933.txt
https://www.libssh.org/2018/10/16/libssh-0-8-4-and-0-7-6-security-and-bugfix-release/
========================

Updated packages in core/updates_testing:
========================
libssh4-0.7.6-1.mga6
libssh-devel-0.7.6-1.mga6

from libssh-0.7.6-1.mga6.src.rpm

Assignee: luigiwalser => qa-bugs

A PoC is available to test this:
https://www.openwall.com/lists/oss-security/2018/10/17/5

Ubuntu has issued an advisory for this today (October 17):
https://usn.ubuntu.com/3795-1/

Severity: normal => major

Replying to David Walser - comment 5.
Working on this.  Installed the build system for the PoC files and ran Cmake to generate various executables.  All that ran smoothly but the actual test tripped on the first hurdle:

$ samplesshd-cb 127.0.0.1 -p 2222
Error listening to socket: Failed to import private DSA host key

Shorewall knows about 2222/tcp.  Don't understand the failure message.  Where should I look for this DSA key?  This is my .ssh directory:
$ ls
authorize        backup     config  id_rsa      known_hosts  pub.difda
authorized_keys  belexeuli  difda   id_rsa.pub  known-hosts

CC: (none) => tarazed25

re comment #7
Most of the files containing public keys have access permissions of 600 which I gather is required and known_hosts contains an ecdsa entry for localhost.

If it is a private key that the new server is looking for then I have no idea - buried in a system database somewhere.

Abandoning this.  To whoever takes it over, the PoC is easy enough to set up but good luck with trying to run it.

Created attachment 10410 [details]
PoC file for CVE-2018-10933

Run after starting the dummy server.

Created attachment 10411 [details]
Dummy ssh server for CVE-2018-10933 PoC

Start dummy server
$ ./samplesshd-cb 127.0.0.1 -p 2222
$ python 10933.py
Expected output is something like
"Allocated session channel
Allocated shell"
before updating.

@Len
Downloaded your files, made samplesshd-cb executable but at CLI:
$ ./samplesshd-cb 127.0.0.1 -p 2222
bash: ./samplesshd-cb: kan binair bestand Verkeerd uitvoerbaar bestand niet uitvoeren
cannot execute binary file Wrong binary file.
$ ls -als
32 -rwxr-xr-x 1 tester6 tester6 31008 okt 25 16:40 samplesshd-cb*

CC: (none) => herman.viaene

Are you on 32-bit for this test Herman?  The binary file is for x86_64.
$ file samplesshd-cb
samplesshd-cb: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=6ac5f34361a359826d239bea3493db5eb3cdaee4, not stripped

It probably is not easy to build the binary if you are unfamiliar with installing from a tarfile.  It involves a build system and running make on the Makefile and in some cases you might have to run ./configure beforehand, especially for a 32-bit architecture.  I could have a look at that in vbox, but not tonight.

@Len Comment 13: Yes, its 32-bit. Too bad,giving up on this update for a while.

We could update again to 0.7.7, which fixes regressions in the CVE fix:
https://www.libssh.org/2018/10/29/libssh-0-8-5-and-libssh-0-7-7/

Done for Cauldron with 0.8.5 release and also for mga6 with 0.7.7 release!

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

Updated libssh packages fix security vulnerability:

libssh versions 0.6 and above have an authentication bypass vulnerability in the
server code.  By presenting the server an SSH2_MSG_USERAUTH_SUCCESS message in
place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to
initiate authentication, the attacker could successfully authentciate without
any credentials (CVE-2018-10933).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10933
https://www.libssh.org/security/advisories/CVE-2018-10933.txt
https://www.libssh.org/2018/10/16/libssh-0-8-4-and-0-7-6-security-and-bugfix-release/
https://www.libssh.org/2018/10/29/libssh-0-8-5-and-libssh-0-7-7/
========================

Updated packages in core/updates_testing:
========================
libssh4-0.7.7-1.mga6
libssh-devel-0.7.7-1.mga6

from libssh-0.7.7-1.mga6.src.rpm

CVE-2018-10933
https://www.exploit-db.com/exploits/45638/

Tried to run the python3 exploit script attached but failed to find module paramiko.  python-paramiko is installed but not the python3 equivalent and trying to install it hits the buffers:
$ sudo urpmi python3-paramiko
A requested package cannot be installed:
python3-cryptography-2.3.1-1.mga6.x86_64 (due to unsatisfied pythonegg(3)(cffi)[>= 1.7])
Continue installation anyway? (Y/n)

Created attachment 10451 [details]
python3 exploit file for CVE-2018-10933

There are dependencies like python3-paramiko (?), python3-cryptography and pythonegg(3)(cffi)[>= 1.7]

Re comment 19.
This is bug https://bugs.mageia.org/show_bug.cgi?id=23810

Returning to this now that we can install python paramiko.

Hit a brick wall with the simple PoC.
The first step is to run a server which I had already compiled.  The second step would be to run the python script attached.  However, there seems to be no way to get the server to run.  That is a lot of work to get nowhere.
After several failed passes I had generated a new DSA key and added tcp/2222 to Shorewall.  Still no luck.

$ samplesshd-cb -v --dsakey=/home/lcl/.ssh/id_dsa --rsakey=/home/lcl/.ssh/id_rsa localhost -p 2222
Enter PEM pass phrase:
[2018/11/10 16:41:11.885107, 1] ssh_bind_import_keys:  Failed to import private RSA host key
Error listening to socket: Failed to import private RSA host key

If you do not supply a DSA key it fails immediately.  If you do, it fails because an RSA key is not specified.  That is why there are two security keys supplied.
Note that the private keys have permissions 600.  Also, I have assumed that the PEM passphrase refers to the password(s) assigned to the respective keys.  There are no visible PEM certificates.

So what have I missed?

If anybody else is tempted to try this one, this is the procedure I worked out to install samplesshd-cb.

Download the tarball from https://www.libssh.org/files/0.7/libssh-0.7.4.tar.xz
$ unxz libssh-0.7.4.tar.xz
Install cmake if necessary; check -> "which cmake".
$ sudo install cmake

Create the libssh-0.7.4 directory tree from the tarball.
Run the following commands, but change the /home/lcl string to your user home directory.  My assumption is that it would be the target directory for
"make install"
which I declined to run.

$ cd libssh-0.7.4
$ mkdir build
$ cd build
$ cmake -DCMAKE_INSTALL_PREFIX=/home/lcl -DCMAKE_BUILD_TYPE=Debug ..
$ make

The build/examples directory should now contain executable files corresponding to the examples source files.  Among them should be samplesshd-cb.  Copy that to somewhere convenient, like your user bin directory, somwhere on your PATH anyway.

Rebuild the binary after updating libssh.

After "make clean" and recompilation of the server there was a little progress:
$ samplesshd-cb 127.0.0.1 -p 2222 -d ~/.ssh/id_dsa -r ~/.ssh/id_rsa
Enter PEM pass phrase:
Enter PEM pass phrase:

Move to another terminal:
$ python poc.py
<no output - hangs>
Ctrl-C
$ python poc.py
Unable to connect.
$ sudo urpmi python3-paramiko
$ python3 45638.py 
<hangs for about 20 seconds>
Unable to connect.
$

The PoC author, Soledad, does not say what happens after the patch.  We know only what a successful exploit returns which leaves the question; is our testing procedure exactly correct or had the software been mended already in lib64ssh2?  My instict is to mistrust my application of the test.

The timeout is probably about a minute or so.  Tried detaching the server, to no avail.  Tried to access port 2222 from another node, using the correct remote address but that did not work either.  Ran a trace on one of the trials but could not interpret the output.  Tried looking at /proc/<pid> for the server but again, not competent to analyze it.
[lcl@difda 18562]$ cat stat
18562 (samplesshd-cb) S 8032 18562 8032 34817 18562 4194304 243 0 0 0 0 0 0 0 20 0 1 0 131946411 34648064 1054 18446744073709551615 4194304 4201964 140725043899648 0 0 0 0 0 0 1 0 0 17 7 0 0 0 0 0 6303104 6304632 8630272 140725043908543 140725043908631 140725043908631 140725043912668 0
[lcl@difda 18562]$ cat io
rchar: 14279
wchar: 0
syscr: 20
syscw: 0
read_bytes: 0
write_bytes: 0
cancelled_write_bytes: 0

Nothing in 18562/net/{sockstat,tcp,udp}

[lcl@difda 18562]$ cat status
Name:	samplesshd-cb
Umask:	0022
State:	S (sleeping)
Tgid:	18562
Ngid:	0
Pid:	18562
PPid:	8032
TracerPid:	0
Uid:	1000	1000	1000	1000
Gid:	1000	1000	1000	1000
FDSize:	256
Groups:	955 1000 
[...]

Giving up.

Tried this again using the simpler PoC file at https://www.openwall.com/lists/oss-security/2018/10/17/5, re comment #5.
Before update:
Started the server:
$ samplesshd-cb -v -d dsakey -r rsakey 127.0.0.1 --port=2222

From another terminal:
$ python simplepoc.py

The server output:
[2018/11/14 19:05:05.180216, 3] ssh_socket_pollcallback:  Received POLLOUT in connecting state
[2018/11/14 19:05:05.180304, 3] ssh_socket_unbuffered_write:  Enabling POLLOUT for socket
[2018/11/14 19:05:05.180572, 3] callback_receive_banner:  Received banner: SSH-2.0-paramiko_2.0.8
[2018/11/14 19:05:05.180583, 1] ssh_server_connection_callback:  SSH client banner: SSH-2.0-paramiko_2.0.8
[2018/11/14 19:05:05.180597, 1] ssh_analyze_banner:  Analyzing banner: SSH-2.0-paramiko_2.0.8
[2018/11/14 19:05:05.180644, 3] ssh_socket_unbuffered_write:  Enabling POLLOUT for socket
[2018/11/14 19:05:05.180653, 3] packet_send2:  packet: wrote [len=516,padding=10,comp=505,payload=505]
[2018/11/14 19:05:05.180926, 3] ssh_packet_socket_callback:  packet: read type 20 [len=596,padding=8,comp=587,payload=587]
[...] <key exchanges>
[2018/11/14 19:05:05.246692, 3] ssh_packet_socket_callback:  packet: read type 52 [len=12,padding=10,comp=1,payload=1]
[2018/11/14 19:05:05.246702, 3] ssh_packet_process:  Dispatching handler for packet type 52
[2018/11/14 19:05:05.246716, 3] ssh_packet_userauth_success:  Authentication successful
[2018/11/14 19:05:05.287296, 3] ssh_packet_socket_callback:  packet: read type 90 [len=44,padding=19,comp=24,payload=24]
[2018/11/14 19:05:05.287306, 3] ssh_packet_process:  Dispatching handler for packet type 90
[2018/11/14 19:05:05.287311, 3] ssh_packet_channel_open:  Clients wants to open a session channel
Allocated session channel
[...]
[2018/11/14 19:05:05.310496, 3] ssh_message_handle_channel_request:  Received a shell channel_request for channel (43:0) (want_reply=1)
Allocated shell
[2018/11/14 19:05:05.310501, 3] ssh_message_channel_request_reply_success:  Sending a channel_request success to channel 0
[2018/11/14 19:05:05.310542, 3] ssh_socket_unbuffered_write:  Enabling POLLOUT for socket
[2018/11/14 19:05:05.310548, 3] packet_send2:  packet: wrote [len=12,padding=6,comp=5,payload=5]
[2018/11/14 19:05:05.410814, 1] ssh_socket_exception_callback:  Socket exception callback: 1 (0)
[2018/11/14 19:05:05.410823, 1] ssh_socket_exception_callback:  Socket error: disconnected
Error : Socket error: disconnected

Going according to plan.

Ran the test with python3 and a slightly modified PoC file and saw the same results after restarting the sample server.

Enabled updates testing and updated the hdlists.  Ran MageiaUpdate and could not see the new packages anywhere.
Updated them manually but that left lib64ssh2 in place.  Noticed this after rebuilding the sample server.Checked the binaries and found that they were the same size and diff came up with 0.
An rpm search showed that the original packages were still installed.  They cannot be removed manually without breaking the system.  No idea how to deal with that situation but shall check the build system files for version requirements, otherwise I have no clue.  Taking a break now.

After an hour or so studying the build system I had found and edited all instances of MAJOR, MINOR, PATCH and other version references to point to 0.7.7-1 and rebuilt the sample server.  Ran it under strace to confirm that the newly installed library was being used and tried the python and python3 tests.  Sadly there is no change:
$ samplesshd-cb -d dsakey -r rsakey 127.0.0.1 --port=2222 
Allocated session channel
Allocated shell
Error : Socket error: disconnected

It looks like the patch has not taken but it is impossible to be certain because there is no indication upstream to suggest what the user should expect.

Not sure what kind of utility testing would suffice here but scp works between local machines and a triple remote login (a triangle) brought the user back to his current machine using authorized_keys.

Adding the feedback marker.  We need to know what the response to the exploit should be.

$ samplesshd-cb 127.0.0.1 -p 2222 -d ./dsakey -r ./rsakey

Tried out the more complex PoC file.

$ python3 45638.py --host=127.0.0.1 -p 2222 -log paramiko.log
Namespace(host='127.0.0.1', logfile='paramiko.log', port='2222')

Server response:
Allocated session channel
Allocated shell
Error : Socket error: disconnected

$ journalctl -xe
[...]
Nov 15 01:20:50 difda pkexec[28119]: pam_systemd(polkit-1:session): Cannot create session: Already running in a session
Nov 15 01:20:50 difda pkexec[28119]: pam_unix(polkit-1:session): session opened for user root by (uid=1000)

Rpmdrake or one of its priority dependencies needs to be updated first. Rpmdrake will then restart.

The following 6 packages are going to be installed:

- aria2-1.25.0-1.1.mga6.x86_64
- lib64gcrypt-devel-1.7.10-1.mga6.x86_64
- lib64gpg-error-devel-1.24-1.mga6.x86_64
- lib64ssh-devel-0.7.7-1.mga6.x86_64
- lib64ssh4-0.7.7-1.mga6.x86_64
- lib64zlib-devel-1.2.11-4.1.mga6.x86_64

1.8MB of additional disk space will be used.

1.6MB of packages will be retrieved.

Is it ok to continue?

--

I then did the commands

ssh-keygen
ssh-add

Took the published rsa.pub key and published on a remote server

I was then able to connect.

This seems like a valid test for libssh.  I'm approving 64-bit

CC: (none) => brtians1
Whiteboard: (none) => MGA6-64-OK

SSH doesn't use libssh.  Check urpmq --whatrequires lib64ssh4 to see what does.

Thanks - sorry for the bad test then.  Removing the ok

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

Installed Remmina and reconnected using SSH.  I had no issues connecting via Remmina to the remote server.

Since I screwed up once on this, I want someone else to make the call if this is sufficient as a test.

The following 6 packages are going to be installed:

- aria2-1.25.0-1.1.mga6.x86_64
- lib64gcrypt-devel-1.7.10-1.mga6.x86_64
- lib64gpg-error-devel-1.24-1.mga6.x86_64
- lib64ssh-devel-0.7.7-1.mga6.x86_64
- lib64ssh4-0.7.7-1.mga6.x86_64
- lib64zlib-devel-1.2.11-4.1.mga6.x86_64

1.8MB of additional disk space will be used.

1.6MB of packages will be retrieved.

Is it ok to continue?


Added to this Remmina

The following 3 packages are going to be installed:

- lib64avahi-ui-gtk3_0-0.6.32-1.mga6.x86_64
- remmina-1.2.32.1-1.mga6.x86_64
- remmina-plugins-common-1.2.32.1-1.mga6.x86_64

2MB of additional disk space will be used.

Looks perfectly valid Brian.  Go ahead.
(Many people would have assumed that ssh utilities would us libssh - as David says, always good to check.)

Please push this update.  We need to trust that upstream fixed what they said they fixed.

Keywords: feedback => (none)

(In reply to David Walser from comment #37)
> Please push this update.
Doing! Many thanks to Len for his long battles, and Brian for wrapping it up.

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

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

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

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