Upstream has issued an advisory on August 26: https://www.libssh.org/security/advisories/CVE-2021-3634.txt The issue is fixed upstream in 0.9.6: https://www.libssh.org/2021/08/26/libssh-0-9-6-security-release/ Mageia 8 is also affected.
Whiteboard: (none) => MGA8TOOStatus comment: (none) => Fixed upstream in 0.9.6CC: (none) => geiger.david68210
Ubuntu has issued an advisory for this on August 26: https://ubuntu.com/security/notices/USN-5053-1
Severity: normal => major
Assigning to DavidG who has dealt with this in the past; CC'ing Joseph who did the most recent update, and may be willing to deal with this.
Assignee: bugsquad => geiger.david68210CC: geiger.david68210 => joequant
Debian has issued an advisory for this on August 31: https://www.debian.org/security/2021/dsa-4965
Reassigning to all packagers collectively, because Daviddavid hasn't been around so far this summer. libssh-0.9.6 built fine in cauldron locally and lib64ssh4-0.9.6 installed fine, too, but I have no understanding of the package and nothing on my system needs lib64ssh4, so I can't test it and therefore won't commit it, sorry.
Assignee: geiger.david68210 => pkg-bugsCC: (none) => geiger.david68210, marja11
Suggested advisory: ======================== The updated packages fix a security vulnerability: A flaw has been found in libssh in versions prior to 0.9.6. The SSH protocol keeps track of two shared secrets during the lifetime of the session. One of them is called secret_hash and the other session_id. Initially, both of them are the same, but after key re-exchange, previous session_id is kept and used as an input to new secret_hash. Historically, both of these buffers had shared length variable, which worked as long as these buffers were same. But the key re-exchange operation can also change the key exchange method, which can be based on hash of different size, eventually creating "secret_hash" of different size than the session_id has. This becomes an issue when the session_id memory is zeroed or when it is used again during second key re-exchange. (CVE-2021-3634) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3634 https://www.libssh.org/security/advisories/CVE-2021-3634.txt https://www.libssh.org/2021/08/26/libssh-0-9-6-security-release/ https://ubuntu.com/security/notices/USN-5053-1 https://www.debian.org/security/2021/dsa-4965 ======================== Updated packages in core/updates_testing: ======================== lib(64)ssh4-0.9.6-1.mga8 lib(64)ssh-devel-0.9.6-1.mga8 from SRPM: libssh-0.9.6-1.mga8.src.rpm
Assignee: pkg-bugs => qa-bugsStatus: NEW => ASSIGNEDStatus comment: Fixed upstream in 0.9.6 => (none)Version: Cauldron => 8Whiteboard: MGA8TOO => (none)CVE: (none) => CVE-2021-3634CC: (none) => nicolas.salguero
MGA8-64 $ uname -a Linux localhost 5.10.62-desktop-1.mga8 #1 SMP Fri Sep 3 14:47:45 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux installed lib64ssh4 - used keygen to generate a new private/public key - published public key - able to connect to remote server with new key seems to work if this is a valid test.
Whiteboard: (none) => MGA8-64-OKCC: (none) => brtians1
Openssh itself doesn't use this library, so you'd have to use something that does for it to be a valid test.
taking off the okay then until I can confirm the library.
Whiteboard: MGA8-64-OK => (none)
installed remmina strace -o lib64ssh4.txt remmina attempted connection to remote linux server in log I see openat(AT_FDCWD, "/lib64/libssh.so.4", O_RDONLY|O_CLOEXEC) = 3 seems to be responding and working.
Whiteboard: (none) => MGA8-64-OK
Validating. Advisory in Comment 5.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
CC: (none) => davidwhodginsKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0441.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED