Upstream has issued an advisory today (October 16): https://www.libssh.org/security/advisories/CVE-2018-10933.txt The issue is fixed upstream in 0.7.6 and 0.8.4: https://www.libssh.org/2018/10/16/libssh-0-8-4-and-0-7-6-security-and-bugfix-release/ Mageia 6 is also affected.
Whiteboard: (none) => MGA6TOO
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 => luigiwalserSource RPM: libssh-0.8.3-1.mga7.src.rpm => libsshCC: (none) => marja11Whiteboard: 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.
Keywords: (none) => feedback
$ 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) => brtians1Whiteboard: (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.)
Whiteboard: (none) => MGA6-64-OK
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_updateCC: (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 => RESOLVEDResolution: (none) => FIXED