[
https://issues.apache.org/jira/browse/SSHD-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny deleted SSHD-1337:
------------------------------------
> 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
> Priority: Major
>
> {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" to its kex_algorithms and the server
> may append "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
