Ingela Andin

A key exchange issue without entity authentication in the ssl module allows a peer responding to a TLS 1.3 client connection to impersonate the intended server. This occurs when a `pre shared key` extension is present in the `ServerHello` that the client did not offer, causing the client to complete the handshake without validating the server certificate. Specifically, `tls client connection 1 3:handle server hello/2` passes the extension to `tls gen connection 1 3:handle resumption/2`, which sets `resumption = true` without verifying if the client offered a PSK. Subsequently, `tls handshake 1 3:get pre shared key/4` falls back to an all-zero value, and the `maybe resumption/1` function routes directly to `wait finished`. This bypasses critical security checks including certificate path validation, `verify fun`, hostname verification, `partial chain`, CRL checking, and OCSP stapling. An attacker can intercept traffic, read sensitive data such as credentials and tokens, and forge responses. This affects any consumer of `ssl:connect` using TLS 1.3, including `httpc` over HTTPS and various database or messaging client libraries.

Sensitive data exposure occurs in the `httpc response` module of the inets library. The `httpc` client forwards `Authorization` and `Proxy-Authorization` request headers to redirect targets without verifying if the redirect crosses an origin boundary. Specifically, the `redirect/2` function constructs the redirected request by updating only the host field of the header record, copying all other fields verbatim. Since `autoredirect` is enabled by default, this affects all callers that do not explicitly disable automatic redirects. An attacker controlling a server can issue a cross-origin 3xx redirect to a server they also control, causing the `Authorization` header (including Basic credentials derived from URL userinfo via the `handle user info/2` function) and the `Proxy-Authorization` header to be forwarded, leading to credential theft.

Improper following of a certificate's chain of trust in the `pubkey cert` module allows a non-CA certificate to be accepted as an intermediate issuer, enabling certificate chain forgery. The function `pubkey cert:validate extensions/7` contains flaws where a certificate with `basicConstraints` set to `cA:false` and no `keyUsage` extension can be used as an intermediate issuer in a chain passed to `public key:pkix path validation/3`. This occurs because the `cA:false` clause does not reject the certificate when it is in the issuer position, and the `keyUsage` check is bypassed if the extension is entirely absent. Consequently, an attacker with an end-entity certificate issued by a trusted CA can sign forged leaf certificates for arbitrary identities. This affects all TLS or mTLS endpoints built on the OTP ssl application using the default verifier, including client-side server identity verification and mTLS server client certificate verification.

Improper Certificate Validation in the `pubkey ocsp` module of Erlang OTP `public key` allows forged Online Certificate Status Protocol (OCSP) responses signed with an expired responder certificate to be accepted as valid. The functions `verify response/5` and `is authorized responder/3` fail to check the validity period (`notBefore`/`notAfter`) of the OCSP responder certificate. An attacker possessing the private key of an expired CA-designated OCSP responder certificate can forge responses that the system accepts. This impacts TLS clients using OCSP stapling via the `ssl` application, potentially allowing a compromised server to present a revoked TLS certificate as valid. It also affects applications directly calling the `pkix ocsp validate/5` function, which may lead to authentication bypass during server-side client certificate validation.

An Allocation of Resources Without Limits or Throttling issue exists in Erlang OTP ssh (ssh sftp modules), potentially leading to Excessive Allocation and Resource Leak Exposure. The issue is associated with the `ssh sftpd.erl` file.

An Allocation of Resources Without Limits or Throttling issue exists in Erlang OTP ssh (ssh sftp modules), potentially leading to Excessive Allocation and Resource Leak Exposure. The issue is associated with the `ssh sftpd.erl` file.

An uncontrolled resource consumption issue exists in Erlang OTP ssh (ssh sftp modules), allowing excessive allocation and flooding. The issue is associated with the `ssh sftpd.erl` file.

An Allocation of Resources Without Limits or Throttling issue exists in the Erlang OTP ssh (ssh sftp modules), potentially leading to Excessive Allocation and Flooding. The vulnerability is associated with the `ssh sftpd.erl` file.