Netty Security Fixes: CORS Cache Poisoning, TLS ClientHello Parsing, SOCKS Validation

Vulnerability Overview This web screenshot shows a Pull Request (PR #17213) for the Netty project, primarily involving multiple security-related fixes and improvements. Below is a summary of the key vulnerabilities: 1. CORS: Don't override vary header if it already exists - Impact: The Netty CorsHandler silently overwrites existing headers, leading to cache poisoning and sensitive information leakage. - Remediation: Set the header only if it does not already exist, and add unit tests. 2. Encoding-side validation of MQTT fields - Impact: The MQTT encoder may generate malformed messages if the client ID, topic, or username contains invalid characters. - Remediation: Add validation for the client ID, topic, and username in the CONNECT message encoding path, and validate the topic name when encoding PUBLISH messages. If these fields contain NUL bytes, the encoder will throw an exception. 3. Correctly handle ClientHello with a handshake header split across TLS records - Impact: The ClientHello handshake header in a TLS record may be split, causing parsing errors. - Remediation: Read the handshake header directly from the record only when a complete 4-byte header is present in the record; otherwise, aggregate the record payload into until at least 4 bytes are available. Add test cases to verify handling of fragment sizes 1–4. 4. Harden the SOCKS4/5 input validation at encoding time - Impact: The SOCKS4 and SOCKS5 protocols do not support NUL bytes or string/byte sequence fields exceeding 255 bytes. - Remediation: Add validation for NUL bytes and length limits for SOCKS4 and SOCKS5, ensuring correct behavior for both client and server encoders. Add test cases to verify handling of boundary conditions. 5. Do not re-aggregate the ClientHello on every received TLS record - Impact: Re-aggregating the ClientHello upon every received TLS record may cause performance issues. - Remediation: Avoid re-aggregating the ClientHello for each received TLS record. 6. Validate trust manager configuration - Impact: Certain trust manager configurations are not validated against the configured endpoint identification algorithm. - Remediation: Add a check that fails if the configured trust manager does not support the required validation mode. Impact Scope These vulnerabilities primarily affect the network communication security of the Netty project, particularly components involving CORS, MQTT, TLS, and SOCKS protocols. Fixing these vulnerabilities enhances system security and stability, preventing cache poisoning, sensitive information leakage, malformed messages, parsing errors, performance degradation, and configuration errors. Remediation CORS: Set the header only if it does not already exist, and add unit tests. MQTT: Add validation for the client ID, topic, and username in the encoding paths for CONNECT and PUBLISH messages. TLS: Read the handshake header directly from the record only when a complete 4-byte header is present in the record; otherwise, aggregate the record payload into until at least 4 bytes are available. Add test cases to verify handling of fragment sizes 1–4. SOCKS4/5: Add validation for NUL bytes and length limits for SOCKS4 and SOCKS5, ensuring correct behavior for both client and server encoders. Add test cases to verify handling of boundary conditions. TLS: Avoid re-aggregating the ClientHello for each received TLS record. Trust Manager Configuration: Add a check that fails if the configured trust manager does not support the required validation mode. POC Code or Exploit Code No specific POC code or exploit code was included in the page.

Goal Reached Thanks to every supporter — we hit 100%!

Netty Security Fixes: CORS Cache Poisoning, TLS ClientHello Parsing, SOCKS Validation

More from this source