Lyor Goldstein created SSHD-1337: ------------------------------------ Summary: New Attacks on SSH Channel Integrity Key: SSHD-1337 URL: https://issues.apache.org/jira/browse/SSHD-1337 Project: MINA SSHD Issue Type: Improvement Reporter: Lyor Goldstein
{quote} We [1] are security researchers from the Ruhr University Bochum, and have discovered new attacks on the SSH channel integrity, which we want to disclose to you. You can find the draft version of our research paper, which we submitted to the USENIX Security conference, in [2]. Please treat it confidential until public disclosure, which is currently planned for 18th of December 2023 (2023-12-18). 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-poly1...@openssh.com) and Encrypt-then-MAC (-e...@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. Two other exploits against AsyncSSH are even more severe, but additionally rely on implementation flaws in AsyncSSH. Mitigations: We already disclosed our findings to the OpenSSH maintainers on 17th of October. Because fixing the flaw requires changes to the SSH specification, we worked together with them 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: - The connection must be terminated if an unexpected or out-of-order message is received during initial key exchange. This includes insertion of any messages like SSH_MSG_IGNORE and similar, or if the SSH_MSG_KEXINIT is not the first message after the banner. - The implicit sequence numbers must be reset on every SSH_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). The patch enables you to build a version of OpenSSH that implements the proposed countermeasures for evaluation and interoperability testing. The patch also includes the amendment to the PROTOCOL file containing the specification for this extension. OpenSSH will release an updated version with these countermeasures on 18th of December 2024. 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. {quote} Draft paper and OpenSSH patch available at: https://drive.google.com/drive/folders/1vJQYPqlaiDghv3jQ_TqOqgIowU_KO9ae?usp=drive_link {quote} Based on feedback, OpenSSH updated the PROTOCOL specification for "strict kex" to resolve some ambiguities. First and foremost, the behaviour when encountering "strict kex" identifiers during key re-exchange is now well-defined. You can find the updated PROTOCOL specification below or in the Google Drive folder that I shared with you during the initial disclosure. If you have any additional feedback regarding this, I'll make sure to pass it along to the OpenSSH team and keep all of you updated. 1.9 transport: strict key exchange extension OpenSSH supports a number of transport-layer hardening measures under a "strict KEX" feature. This feature is signalled similarly to the RFC8305 ext-info feature: by including a additional algorithm in the initiial SSH2_MSG_KEXINIT kex_algorithms field. The client may append "kex-strict-c-...@openssh.com" <kex-strict-c-...@openssh.com> to its kex_algorithms and the server may append "kex-strict-s-...@openssh.com" <kex-strict-s-...@openssh.com>. These pseudo-algorithms are only valid in the initial SSH2_MSG_KEXINIT and MUST be ignored if they are present in subsequent SSH2_MSG_KEXINIT packets. When an endpoint that supports this extension observes this algorithm name in a peer's KEXINIT packet, it MUST make the following changes to the the protocol: a) 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. b) At each SSH2_MSG_NEWKEYS message, reset the packet sequence number to zero. This behaviour persists for the duration of the connection (i.e. not just the first SSH2_MSG_NEWKEYS). {quote} -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org