GHSA-wvc4-j7g5-4f79 – nats

Package

Manager: cargo
Name: nats
Vulnerable Version: >=0.9.0 <0.24.1

Severity

Level: Medium

CVSS v3.1: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N/E:P/RL:O/RC:C

CVSS v4.0: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

EPSS: N/A pctlN/A

Details

NATS TLS certificate common name validation bypass The NATS official Rust clients are vulnerable to MitM when using TLS. A fix for the `nats` crate hasn't been released yet. Since the `nats` crate is going to be deprecated anyway, consider switching to `async-nats` `>= 0.29` which already fixed this vulnerability. The common name of the server's TLS certificate is validated against the `host`name provided by the server's plaintext `INFO` message during the initial connection setup phase. A MitM proxy can tamper with the `host` field's value by substituting it with the common name of a valid certificate it controls, fooling the client into accepting it. ## Reproduction steps 1. The NATS Rust client tries to establish a new connection 2. The connection is intercepted by a MitM proxy 3. The proxy makes a separate connection to the NATS server 4. The NATS server replies with an `INFO` message 5. The proxy reads the `INFO`, alters the `host` JSON field and passes the tampered `INFO` back to the client 6. The proxy upgrades the client connection to TLS, presenting a certificate issued by a certificate authority present in the client's keychain. In the previous step the `host` was set to the common name of said certificate 7. `rustls` accepts the certificate, having verified that the common name matches the attacker-controlled value it was given 9. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate

Metadata

Created: 2023-03-27T21:12:24Z
Modified: 2023-03-27T21:12:24Z
Source: https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2023/03/GHSA-wvc4-j7g5-4f79/GHSA-wvc4-j7g5-4f79.json
CWE IDs: ["CWE-347"]
Alternative ID: N/A
Finding: F163
Auto approve: 1