Bugzilla – Bug 1218194
VUL-0: CVE-2023-48795: rubygem-net-ssh,rubygem-net-ssh-6.1: prefix truncation breaking ssh channel integrity aka Terrapin Attack
Last modified: 2024-07-03 08:09:37 UTC
This bug tracks rubygem-net-ssh and rubygem-net-ssh-6.1 affectedness bny the Terrapin attack. +++ This bug was initially created as a clone of Bug #1217950 +++ via distros CRD: 2023-12-18 Hello, Please treat this message confidential until public disclosure, which is set for 18th of December 2023 15:00 UTC (2023-12-18T15:00:00Z). No immediate action or response by you is required. We are providing you this information in case it is useful for you to estimate the impact of the public disclosure on your organization and, in particular, to plan any resources you might require in response to the public disclosure. We [1] are security researchers from the Ruhr University Bochum and have discovered new attacks on the SSH channel integrity, which we have disclosed to the vendors and open-source projects. You can find the draft version of our research paper, which we submitted to the USENIX Security Conference, in [2]. Prefix truncation attack on BPP: By manipulating sequence numbers during the handshake, an attacker can remove the initial messages on the secure channel without causing a MAC failure. The vulnerable cipher modes are ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com MAC algorithms). Practical Exploits and Impact: With channel integrity broken, we also show several exploits. An extension negotiation downgrade attack undermines channel security by removing the extension info message and works against all compliant implementations. For example, an attacker can disable the ping extension and thus disable the new countermeasure in OpenSSH 9.5 against keystroke timing attacks. We also show how the prefix truncation attack can be mounted to exploit previously unexploitable implementation flaws as a Man-in-the-Middle attacker by the example of AsyncSSH. Mitigations: We disclosed our findings to vendors of SSH implementations previously (see below for a list of contacted vendors). Because fixing the flaw requires changes to the SSH specification, we worked together with OpenSSH to come up with a specific countermeasure that ensures interoperability. We support the proposed changes in OpenSSH called "strict kex", which is negotiated as part of the SSH_MSG_KEXINIT. When negotiated, the following changes to the protocol are made: - During initial KEX, terminate the connection if any unexpected or out-of-sequence packet is received. This includes terminating the connection if the first packet received is not SSH2_MSG_KEXINIT. Unexpected packets for the purpose of strict KEX include messages that are otherwise valid at any time during the connection such as SSH2_MSG_DEBUG and SSH2_MSG_IGNORE. - At each SSH2_MSG_NEWKEYS message, reset the packet sequence number to zero. This behavior persists for the duration of the connection (i.e. not just the first SSH2_MSG_NEWKEYS). The OpenSSH project was kind enough to share with us, ahead of time, a "strict kex" patch that implements these changes (can be found in [2] as well). Note that this patch is not final and subject to minor changes by the OpenSSH developers. The patch enables you to build a version of OpenSSH that implements the proposed countermeasures for evaluation and interoperability testing. The specification for "strict kex" can be found in PROTOCOL_Strict_Kex_v2.txt (note that the patch includes an older revision of this specification). OpenSSH will release an updated version with these countermeasures on the 18th of December, 2023. As with our findings, we ask that you treat this patch confidential until public disclosure. As an alternative, less invasive countermeasure, the affected cipher modes chacha20-poly1305 and any encrypt-then-mac variants (generic EtM) may be (temporarily) disabled. Some cipher modes, in particular AES-GCM, are not affected by our findings and can still be used without changes. Coordinated Disclosure: This vulnerability was assigned CVE-2023-48795. Please consider using this CVE number when communicating the vulnerability on December 18th. Our initial assessment yielded a CVSS3.1 score of 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N), and CVSS4 score of 8.2 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N). We contacted the vendors of the following SSH implementations during the process, and we expect a majority of them to provide a patch on December 18th: OpenSSH, Dropbear, Bitvise SSH / FlowSsh, Tectia SSH, AsyncSSH, libssh, PuTTY, ProFTPD (mod_sftp), PKIX-SSH, Termius, ConnectBot, JSch (fork by mwiede), Golang Crypto SSH package, Russh, ssh2, Apache MINA SSHD, SecureCRT, TeraTerm, Paramiko, libssh2, CycloneSSH, Erlang SSH library, SSHJ, Thrussh, XShell, SSH Server for Windows (Georgia Softworks), JAdaptive Maverick. Public Disclosure: Public disclosure is set for the 18th of December 2023 at 15:00 UTC (2023-12-18T15:00:00Z). We will publish a preprint of our paper and an informational website for system administrators alongside the patches. The website will become available at: https://terrapin-attack.com Of course, we are happy to discuss our results and answer any questions you might have. Kindly, Fabian, Marcus, and J??rg [1] We are: Fabian B??umer <fabian.baeumer@rub.de> Marcus Brinkmann <marcus.brinkmann@rub.de> J??rg Schwenk <joerg.schwenk@rub.de> [2] Draft paper and OpenSSH patch available at: https://drive.google.com/drive/folders/1vJQYPqlaiDghv3jQ_TqOqgIowU_KO9ae?usp=drive_link -- M. Sc. Fabian B??umer Chair for Network and Data Security
openSUSE:Backports:SLE-15-SP4:Update/rubygem-net-ssh openSUSE:Backports:SLE-15-SP5:Update/rubygem-net-ssh openSUSE:Factory rubygem-net-ssh also in openstack cloud, but there I would just leave it unfixed