[
https://issues.apache.org/jira/browse/SSHD-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-1337:
---------------------------------
Description:
{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}
was:
{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}
> 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
