GHSA-m7j3-vh25-xc8p: NetX Secure TLS accepts unauthenticated empty application records

NetX Secure TLS accepts an empty application-data record without verifying its message authentication code. In _nx_secure_verify_mac, a decrypted application record whose length equals the negotiated MAC size is treated as valid and returns success after advancing the receive sequence number. The received MAC is never generated or compared.

Empty TLS application-data records are legal, and are commonly emitted by TLS 1.0 implementations as a BEAST mitigation.

The MAC verification path computes the payload length by subtracting the negotiated MAC size from the record length. When those are equal the payload is zero bytes, and the function takes that as a special case: it returns success directly rather than running the zero-length payload through MAC generation and comparison.

Because the sequence number is advanced on that path, the receiver’s record state moves forward for a record whose integrity was never established.

For TLS 1.2 and earlier cipher suites that use a separate record MAC, an active network attacker able to modify or replay ciphertext can have an altered empty application record accepted instead of rejected. This violates TLS record integrity and advances the receiver’s record sequence state.

The demonstrated practical consequence is connection disruption or denial of service. No path to forging non-empty application data has been established.

AEAD cipher suites do not use this MAC-verification path and are not affected.

NetX Secure builds negotiating TLS 1.2 or earlier with a cipher suite that uses a separate record MAC. AEAD suites are unaffected.

NetX Duo releases from 6.2.0 up to and including 6.5.1.202602.

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

I:L reflects that record integrity is broken for empty records only, with no demonstrated path to forging application data. AC:H reflects that the attacker must already be positioned to modify or replay ciphertext on an established session.

Fixed in NetX Duo 6.5.2.202603. An empty application record is processed through the normal MAC generation and comparison path with a zero-length payload, rather than short-circuiting to success. Records carrying fewer bytes than the negotiated MAC size are rejected, and zero-length non-application records continue to be rejected.

A related record-processing defect is fixed at the same time: when an authenticated empty application record ends exactly at a TCP packet boundary, the consumed record offset is preserved and the parser waits for the next TCP packet instead of reading another TLS header past the end of the current one.

Regression coverage verifies valid and modified empty-record MACs, coalesced empty records, and empty records ending at a TCP packet boundary.

Negotiating an AEAD cipher suite avoids the affected path entirely, since AEAD suites do not use separate record MAC verification.

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