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
