This bug tracks "apache-sshd",  yet another Java SSH application.

It suport chacha20-poly1305.

+++ 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