Skip to content

GHSA-45x7-px36-x8w8 CVE-2023-48795 GO-2023-2402 PYSEC-2026-1758

Prefix Truncation Attack against ChaCha20-Poly1305 and Encrypt-then-MAC aka Terrapin

Medium GoPyPIcrates.io
Severity
5.9 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
93.55%
Chance of exploitation in the next 30 days. Higher than 99.84% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-345 Insufficient Verification of Data Authenticity
CWE-354 Improper Validation of Integrity Check Value
Fix
Available
3 packages have a fixed version

Description

Summary

Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.

Mitigations

To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes.

Warning: To take effect, both the client and server must support this countermeasure.

As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.

Details

The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (*-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSH_MSG_EXT_INFO sent after the first message after SSH_MSG_NEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario.

The attack works by an attacker injecting an arbitrary number of SSH_MSG_IGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSH_MSG_IGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange.

In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers.

For more details see https://terrapin-attack.com.

Impact

This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (*-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.

Affected versions

Go

PackageVulnerableFixed in
golang.org/x/crypto
>= 0.1.0, < 0.17.0
0.17.0
golang.org/x/crypto
< 0.0.0-20231218163308-9d2ee975ef9f
0.0.0-20231218163308-9d2ee975ef9f
golang.org/x/crypto
>= 0.1.0, < 0.17.0
0.17.0
golang.org/x/crypto
< 0.0.0-20231218163308-9d2ee975ef9f
0.0.0-20231218163308-9d2ee975ef9f
golang.org/x/crypto
< 0.17.0
0.17.0

PyPI

PackageVulnerableFixed in
paramiko
>= 2.5.0, < 3.4.0
3.4.0
paramiko
>= 2.5.0, < 3.4.0
3.4.0

crates.io

PackageVulnerableFixed in
russh
< 0.40.2
0.40.2
russh
< 0.40.2
0.40.2

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

golang.org/x/crypto Go → 0.17.0

go
go get golang.org/x/crypto@v0.17.0 && go mod tidy

paramiko PyPI → 3.4.0

pip
pip install --upgrade "paramiko>=3.4.0"
poetry
poetry add "paramiko>=3.4.0"
uv
uv add "paramiko>=3.4.0"

russh crates.io → 0.40.2

cargo
cargo update -p russh --precise 0.40.2

Severity breakdown

CVSS 3.1 5.9

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

Weakness

CWE-345: Insufficient Verification of Data Authenticity

The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.

CWE-354: Improper Validation of Integrity Check Value

The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.

How to prevent it
  • Implementation: Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.

References

Advisories

Fixes and patches

Packages

Other links

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-vp5q-ff62-jwqv
russh: Agent server never calls `Agent::confirm`, so keys added with the confirm constraint (`ssh-add -c`) sign without confirmation
High Also affects russh
GHSA-fw5c-8223-6h42
russh: peer-declared zero maximum packet size permanently stalls channel writes (silent AsyncWrite hang)
Medium Also affects russh
GHSA-9wfm-jcj8-jfv9
russh's SSH agent server is susceptible to unbound allocations via repeated SSH_AGENT_CONSTRAIN_CONFIRM messages
Low Also affects russh
GHSA-4p9f-7p9m-5vfg
russh's SSH client is susceptible to unbounded allocations via EXT_INFO packets
Medium Also affects russh
GHSA-4wc5-f2rc-q74m
russh: Unbounded memory allocation in agent protocol server via crafted constraint records
Medium Also affects russh
GHSA-j7h2-66j4-ghjf
A russh SSH server accepts a publickey authentication whose signature uses a different algorithm than the one named in the request
Low Also affects russh
GHSA-g6xm-f9xp-qq35
Russh: Configured server auth-attempt cap is not enforced in the USERAUTH_REQUEST runtime path
Low Also affects russh
GHSA-w3jg-pjxf-73p4
Russh: Missing X25519 zero-point validation in hybrid ML-KEM key exchange
Medium Also affects russh

Credits: Fabian Bäumer (Ruhr University Bochum), Jörg Schwenk (Ruhr University Bochum), Marcus Brinkmann (Ruhr University Bochum), TrueSkrillor, lambdafu, levpachmanov, sugar700

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor