Upstream OpenSSH committed a partial mitigation in 8.4 for a security issue: https://www.openwall.com/lists/oss-security/2020/12/02/1 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14145 There seems to be a bit of arguing going around about this issue. Obviously when connecting to an SSH host for the first time, you're going to accept the host key presented and there isn't really a way to know whether it's valid or a malicious MiTM, however, a comment in RedHat's Bugzilla says that with this particular issue, clients who have previously connected to a legitimate host won't be able to detect the malicious MiTM without the upstream mitigation, which suggests that we should backport the patch if possible: https://bugzilla.redhat.com/show_bug.cgi?id=1852930#c11
SUSE has issued an advisory for this on December 9: https://lists.suse.com/pipermail/sle-security-updates/2020-December/007952.html
openSUSE has issued an advisory for this on December 13: https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/OTSUNUWKKFI2BZV3IR5RLHAQFXINNKM7/
Status comment: (none) => Patch available from openSUSE
patch used : https://anongit.mindrot.org/openssh.git/commit/?id=b3855ff053f5078ec3d3c653cdaedefaa5fc362d src: - openssh-8.0p1-1.1.mga7
CC: (none) => mageiaAssignee: guillomovitch => qa-bugsStatus comment: Patch available from openSUSE => (none)
Advisory: ======================== Updated openssh packages fix security vulnerability: The client side in OpenSSH 5.7 through 8.3 has an Observable Discrepancy leading to an information leak in the algorithm negotiation. This allows man-in-the-middle attackers to target initial connection attempts (where no host key for the server has been cached by the client) (CVE-2020-14145). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14145 https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/OTSUNUWKKFI2BZV3IR5RLHAQFXINNKM7/ ======================== Updated packages in core/updates_testing: ======================== openssh-8.0p1-1.1.mga7 openssh-clients-8.0p1-1.1.mga7 openssh-server-8.0p1-1.1.mga7 openssh-askpass-common-8.0p1-1.1.mga7 openssh-askpass-8.0p1-1.1.mga7 openssh-askpass-gnome-8.0p1-1.1.mga7 openssh-ldap-8.0p1-1.1.mga7 from openssh-8.0p1-1.1.mga7.src.rpm
Installed and tested without issues. Tested: - normal shell (client and server); - sshfs mount (client and server); - git clone from github, gitlab and local using ssh (client, server); - sftp get, put and a few other commands (client and server); - scp copy to and from (client and server); - rsync to and from (client and server); - ansible to several containers, VMs and local machines (client and server); No issues found. System: Mageia 6, x86_64, Intel CPU. $ uname -a Linux marte 5.10.20-desktop-2.mga7 #1 SMP Fri Mar 5 20:47:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | grep openssh openssh-8.0p1-1.1.mga7 openssh-askpass-common-8.0p1-1.1.mga7 openssh-server-8.0p1-1.1.mga7 openssh-askpass-qt5-2.1.0-3.1.mga7 openssh-clients-8.0p1-1.1.mga7
CC: (none) => mageiaWhiteboard: (none) => MGA7-64-OK
Validating. Advisory in Comment 4.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Advisory committed to svn.
Keywords: (none) => advisoryCVE: (none) => CVE-2020-14145CC: (none) => ouaurelien
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0118.html
Status: NEW => RESOLVEDResolution: (none) => FIXED