Normanmaurer

The library implements Oblivious HTTP (RFC 9458) using BoringSSL's HPKE C library via JNI. When `sun.misc.Unsafe` is unavailable—such as when the JVM is started with `-Dio.netty.noUnsafe=true`, when a SecurityManager restricts access, or on non-HotSpot JVMs—a fallback path is provided for direct ByteBufs that do not expose their memory address through `hasMemoryAddress()`. In these configurations, an unauthenticated network attacker can trigger cryptographic operations with crafted OHTTP requests to corrupt memory belonging to other concurrent connections and disclose the contents of adjacent pooled direct buffers. This occurs regardless of whether the AEAD (Authenticated Encryption with Associated Data) tag verification succeeds, as BoringSSL zeroizes the output buffer on failure. The information disclosure provides the encryption key required to extract the leaked data, compromising the confidentiality and integrity of all connections sharing the same Netty buffer arena.

The `HKDF expand()` function returns a non-NULL byte array filled with zeros upon failure, making it impossible to distinguish between a successful operation and a failure. This output serves as key material for the response AEAD (Authenticated Encryption with Associated Data), meaning a failure results in an all-zero key. Similarly, when `EVP HPKE CTX export` fails, it returns an empty byte array filled with zeros, which is passed to the `createResponseAEAD()` function in `OHttpCrypto`. This behavior allows for the creation of a deterministic and predictable AEAD key.

The issue is related to an infinite recursion when parsing a malformed crafted message, which can lead to a StackOverflowError. This can be exploited by a remote attacker to cause a denial of service. The recursion occurs when parsing a TLV with type = PP2 TYPE SSL, where the value can be another TLV with the same type, and so on. The only limitation to the recursion is the TLV length, which cannot exceed 0xffff due to its encoding in an unsigned short type. Providing a TLV with a sufficiently large nesting level can cause a StackOverflowError.

The issue allows remote attackers to cause a denial of service, resulting in an infinite loop and CPU consumption, via a crafted SSLv2Hello message.