Lukas Backström

Inefficient algorithmic complexity in the asn1 OBJECT IDENTIFIER decoder allows a remote unauthenticated attacker to cause a denial of service by sending a crafted OID during the TLS handshake. The issue occurs because the decoder accumulates a base-128 subidentifier into an unbounded integer, resulting in quadratic total work relative to the size of a single subidentifier. This behavior is present in the `asn1rtt ber:dec subidentifiers/3` function within `lib/asn1/src/asn1rtt ber.erl`, the `asn1rtt per common:dec subidentifiers/3` function in `lib/asn1/src/asn1rtt per common.erl`, and the `asn1rtt jer:json2oid/1` function in `lib/asn1/src/asn1rtt jer.erl`. The vulnerable decoder is used in every ASN.1 module containing an OBJECT IDENTIFIER, including `OTP-PUB-KEY` during X.509 certificate parsing via `public key:pkix decode cert/2`. Since this process occurs before signature or trust chain verification, any Erlang service parsing peer TLS certificates, such as TLS clients or mutual-TLS servers, is exposed.

A resource leak in the `inets httpd` module allows an unauthenticated remote attacker to cause a denial of service. By sending a request with a chunked body where the chunk-size line is not a hexadecimal number, and ensuring this line arrives in a separate write from the headers, the attacker can cause the worker serving the connection to be trapped. Specifically, the `httpd request handler:handle info/2` function converts a throw from `http chunk:decode size/4` into a return value, causing the worker to wait indefinitely for data that never arrives. Since the request timeout is cancelled after headers are accepted and the byte-rate check is disabled by default, repeating this request across multiple connections can occupy all available workers, denying service to legitimate clients.

The ssl application fails to detect cycles when reconstructing an incomplete peer certificate chain during a TLS or DTLS handshake. Specifically, the function `handle incomplete chain/5` passes the chain to `build certificate chain/5`, which then uses `do certificate chain/7` to walk issuer relationships without a depth limit or cycle detection. If a peer provides two mutually cross-signed certificates in an unordered form, the system recurses indefinitely, causing the call stack and chain accumulator to grow without bound. An unauthenticated remote attacker can exploit this by sending a crafted certificate chain in a handshake message to exhaust memory and crash the BEAM node. This affects both servers and clients and requires only a TCP connection and a partial handshake.

An integer underflow exists in the External Term Format (ETF) decoder within the `BIT BINARY EXT` tag (77) handler. When the decoder accepts an encoding where both length and trailing-bits fields are set to zero, the bitstring size computation underflows an unsigned integer. This results in an extremely large value (approximately 2^64) being passed as a memory allocation size, causing the allocator to abort the entire node. This VM-level abort cannot be intercepted by supervision trees, try/catch blocks, or the `[safe]` option in `binary to term/2`. Applications decoding ETF from untrusted sources using `binary to term/1,2` or `enif binary to term()` are exposed. The Erlang distribution protocol also uses this code path, though it is intended for trusted networks.

Resource allocation without limits in the certificate path validation of the public key module allows a remote unauthenticated attacker to cause a denial of service. By sending a crafted X.509 certificate chain during a TLS handshake, an attacker can trigger unbounded growth of the certificate policy tree during RFC 5280 policy processing in the `pkix path validation/3` function. This occurs because the functions `pubkey policy tree:add leaves/2` and `pubkey policy tree:add leaf siblings/2` extend the tree per policy per certificate, leading to exponential growth. This can pin BEAM schedulers and exhaust node memory, resulting in a complete virtual machine crash. The issue affects any incoming or outgoing TLS connection that validates the peer's chain, such as SSL/TLS clients and mutual-TLS servers.

The ssl application fails to validate that the PSK identity list and binder list in a TLS 1.3 ClientHello pre-shared key extension have equal length. In the function `handle pre shared key/3`, an `OfferedPreSharedKeys` record with mismatched lengths is passed to `use/4`, causing the session ticket handler process to crash. An unauthenticated remote attacker can send a crafted ClientHello to a TLS 1.3 server with session tickets enabled to disrupt session ticket handling. While new TLS 1.3 handshakes may complete, they crash when the server attempts to issue a session ticket, rendering TLS 1.3 unusable on the listener until the application is restarted. TLS 1.2 connections are not affected.

An infinite loop exists in the `ssh sftpd` module of Erlang OTP. An authenticated SFTP user can cause an SFTP channel to become permanently unresponsive by sending `SSH MSG CHANNEL EXTENDED DATA` with a non-zero type code, an empty pending buffer, and a payload within the SFTP packet size limit. This triggers a tail-recursive loop in the `handle data()` function, causing the process to stop processing messages and leading to unbounded message queue memory growth and high CPU consumption. The impact is a denial of service on targeted SFTP channels. This effect can be amplified if the `max channels` setting is set to infinity, allowing a single user to open unlimited channels.

Use of a default cryptographic key in the DTLS server allows for predictable DTLS cookie computation during the startup window, which enables the bypass of source address verification. Upon server startup, the function `dtls server connection:initial hello/3` initializes the `previous cookie secret` variable to an empty binary instead of a random value. Since HMAC with an empty key is deterministic, an attacker observing the plaintext ClientHello can compute the `dtls handshake:cookie()` and forge a valid DTLS cookie before the first secret rotation occurs (typically within 0 to 15 seconds). This allows for DTLS handshake amplification using spoofed source addresses, bypassing the denial-of-service mitigation intended to prevent spoofed IPs from forcing the server to allocate state and perform expensive cryptographic operations.

Improper enforcement of message integrity during transmission in the `tls gen connection` module allows a network-positioned attacker to inject unauthenticated plaintext that the TLS client application later treats as authenticated server data. The function `handle protocol record()` fails to reject APPLICATION DATA records that arrive in pre-handshake states when the endpoint acts as a client. An attacker can send plaintext APPLICATION DATA records during the handshake, which are buffered and delivered to the application as authenticated post-handshake data once the handshake completes. This results in the blind injection of unauthenticated bytes. The injection window is wider for TLS versions prior to TLS 1.3 than for TLS 1.3.

A Time-of-check Time-of-use (TOCTOU) race condition exists in the `dtls packet demux` module within the ssl component. This occurs when a DTLS server listener uses a shared `dtls packet demux` `gen server` process to route UDP datagrams. An unauthenticated remote attacker can trigger a crash by rapidly sending multiple ClientHello messages from the same source address and port. This creates a race condition in the internal `gb trees` key-value store, resulting in a `{key exists, {old, Client}}` crash that terminates the demux process. Since this process is shared, all active DTLS sessions on the listener are terminated, leading to a persistent denial of service. The issue is located in the file `lib/ssl/src/dtls packet demux.erl` and only affects deployments using `ssl:listen/2` with UDP-based transport.

An issue in the `inet tls dist` module allows an unauthenticated bypass of the LAN allowlist for Erlang distribution over TLS. The `check ip()` function incorrectly calls `sockname()` instead of `peername()` to retrieve the peer's IP address. Since `sockname()` returns the local socket address, the subnet mask comparison always succeeds regardless of the actual remote address. Consequently, any holder of a CA-signed TLS certificate can bypass LAN restrictions and gain full distribution access to the node, including the ability to use `rpc:call()` and `code:load binary()` functions.

The issue is related to a Path Traversal vulnerability in Erlang OTP, specifically in the stdlib modules. This vulnerability allows Absolute Path Traversal and File Manipulation. It is associated with the program files lib/stdlib/src/zip.erl and the routines `zip:unzip/1`, `zip:unzip/2`, `zip:extract/1`, and `zip:extract/2`, unless the memory option is used.