GHSA-rcv5-vfff-25gh: Out-of-bounds Write via an Unbounded RSA Modulus in NetX Secure X.509

The X.509 parser in NetX Secure accepts an RSA public key of any size, but every signature-verification path decrypts into fixed-size buffers dimensioned for the NX_CRYPTO_MAX_RSA_MODULUS_SIZE default of 4096 bits. A certificate carrying a larger modulus drives an out-of-bounds write past a file-scope static during ordinary certificate-chain verification.

It is reachable pre-authentication. The issuer used for the crypto operation is looked up in the remote, peer-supplied store before the trusted store, so the attacker supplies the oversized key themselves as an intermediate in the chain they present. It triggers on a TLS or DTLS client verifying a malicious server’s chain, and on a server performing client-certificate authentication.

Four independent checks are absent, and any one of them would have stopped it.

The parser accepts any modulus size. _nx_secure_x509_extract_oid_data takes the modulus length straight from the certificate DER with no upper bound. The field is a USHORT, so it admits up to 65535 bytes. The RSA branch guards only the underflow case.

The verification buffer is a fixed 512-byte static. _nx_secure_x509_certificate_verify decrypts into a file-scope array sized for a 4096-bit modulus.

_nx_crypto_method_rsa_init performs no key-size validation. It checks only that the metadata area is large enough for NX_CRYPTO_RSA, then stores the caller’s key size verbatim.

The one output-size check that exists is vacuous on this path. _nx_crypto_method_rsa_operation compares the output buffer length against the key size in bytes — but _nx_secure_x509_certificate_verify passes the issuer’s exponent as the key, so the comparison is against an exponent length of typically three bytes. The modulus length reaches the operation separately, through the context established at init.

The write itself is then unbounded. _nx_crypto_rsa_operation extracts the result using the modulus length as the byte-stream size. _nx_crypto_huge_number_extract does bound-check, but against that same attacker-controlled value rather than against the capacity of the destination, so the guard is satisfied while the copy runs off the end of the buffer.

An 8192-bit key overruns by 512 bytes; the USHORT length allows roughly 64 KiB.

Pre-authentication. The issuer search order is the remote store before the trusted store, so the oversized key is one the attacker ships in their own chain. No credentials and no prior trust relationship are needed.

This is an out-of-bounds write, not merely a read. The bytes written are s^e mod n with the signature, exponent and modulus all chosen by the attacker, so the content is strongly attacker-influenced rather than incidental.

generated_hash, the buffer holding the digest the signature is checked against, is a file-scope static in the same translation unit. Corruption of neighbouring .bss is the primary concern. A specific exploitation path has not been developed.

Clients and servers are affected alike, wherever a peer certificate chain is verified.

Any NetX Secure build that verifies a peer certificate chain — TLS and DTLS clients, and servers with client-certificate authentication enabled. No build option disables the affected path while leaving certificate verification usable.

Every NetX Duo release up to and including 6.5.1.202602.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — 9.8, Critical.

AC:L reflects that the oversized key is simply presented in the attacker’s own chain, with no race, no grooming and no secret required, and that the overrun length and content follow deterministically from values the attacker chooses.

Fixed in NetX Duo 6.5.2.202603. _nx_secure_x509_extract_oid_data refuses an RSA modulus larger than NX_CRYPTO_MAX_RSA_MODULUS_SIZE, so an oversized key is rejected when the certificate is parsed rather than when it is used, and _nx_crypto_method_rsa_init refuses the same key size independently. The parser bound also refuses an INTEGER with no leading byte to skip, instead of wrapping its length. A regression test uses a real 8192-bit certificate and fails on the code before the change.

None. Certificate-chain verification is the affected path, and disabling it is not a mitigation.

Found and fixed by Frédéric Desbiens (@fdesbiens) during review of the CertificateVerify buffer work. The analysis, fix and regression test were produced with AI assistance under human review, in accordance with the Eclipse Foundation’s Generative AI Usage Guidelines.