## Basic information Project name: Eclipse OpenJ9 Project id: technology.openj9 ## What this finding is All four sibling findings in this family are the `jitserver` process, acting as a network **server**, parsing untrusted bytes sent by a connecting **client**. This finding is the reverse direction: a real JVM started with `-XX:+UseJITServer` acts as a network **client**, connects out to a configured JITServer address, and parses **reply** messages coming back from whatever answers on that address. If that peer is a malicious or already-compromised JITServer, a single crafted reply message crashes the connecting **client** JVM, not the server. ## Details of the issue `ClientStream::getRecvData<T...>()` is a one-line forward to the exact same `getArgsRaw<T...>()` / `RawTypeConvert<T>::onRecv()` template machinery already reported vulnerable on the server side. There is no separate, client-specific, more defensive decode path: ```cpp template <typename ...T> std::tuple<T...> getRecvData() { return getArgsRaw<T...>(_sMsg); } ``` https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/ClientStream.hpp#L130-L134 The vulnerable template itself -- the unbounded `for (uint32_t i = 0; i < size; ++i)` loop over `curDesc->getNextDescriptor()`, with `size` taken directly from an attacker-controlled `UINT32` field and never checked against the message's actual remaining bytes -- is defined exactly once in the whole compiler tree and used by both sides: https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/RawTypeConvert.hpp#L149-L181 `getArgsRaw<Args...>()`, the free function `getRecvData<T...>()` forwards to: https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/RawTypeConvert.hpp#L335-L341 `DataDescriptor::getNextDescriptor()`, the unchecked pointer advance the loop above calls once per declared element, pure pointer arithmetic with no bounds check of any kind: https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/Message.hpp#L198-L201 ### The client has strictly less protection than the server on this path `ServerStream::read<T...>()`, the server-side equivalent read path used to receive replies to its own outbound queries, checks that the received message's type matches the type the server actually asked for, and throws `StreamMessageTypeMismatch` otherwise: ```cpp default: { // We are expecting the response type (_cMsg.type()) to be the same as the request type (_sMsg.type()) if (_cMsg.type() != _sMsg.type()) throw StreamMessageTypeMismatch(_sMsg.type(), _cMsg.type()); } ``` https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/ServerStream.hpp#L116-L142 `ClientStream::read()` has no equivalent check anywhere in its body. It reads whatever message arrives and returns its type verbatim, with no correlation to what the client last asked for: ```cpp MessageType read() { readMessage(_sMsg); return _sMsg.type(); } ``` https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/ClientStream.hpp#L121-L125 That returned type is then switched on directly by `handleResponse()`/`handleServerMessage()` in `JITClientCompilationThread.cpp`, which calls `getRecvData<...>()` with whatever tuple shape corresponds to that server-declared type. This confirmed, source-verified fact means a malicious server fully controls which decode handler and which tuple shape runs on the client, purely via the type field of its own reply, with zero correlation checking. This report exploits the simplest such handler; it is not the only one reachable this way. ### The call site exercised by this PoC `handleResponse()` in `JITClientCompilationThread.cpp` contains the following case, reached whenever the client is servicing a remote compile and the server replies with this message type: ```cpp case MessageType::AOTCache_getROMClassBatch: { std::vector<J9Class *> extraClasses; auto recv = client->getRecvData<std::vector<J9Class *>>(); // target auto &ramClasses = std::get<0>(recv); ... client->write(response, classInfos, extraClasses); } break; ``` https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/control/JITClientCompilationThread.cpp#L2982-L2989 This is the simplest possible target: a single-field tuple (`numDataPoints == 1`), the field a `std::vector<pointer-type>`, exactly the shape already confirmed exploitable server-side. `MessageType::AOTCache_getROMClassBatch`'s enum position: https://github.com/eclipse-openj9/openj9/blob/f0754f410244ad2c42b07c5fe76983a3c7b61e87/runtime/compiler/net/MessageTypes.hpp#L295 Its numeric ordinal is build-dependent (it sits after a `#if defined(J9VM_OPT_METHOD_HANDLE)` guarded block), so it was derived empirically for the exact tested build rather than assumed -- see "Determining the ordinal" below. ### Determining the ordinal `grep -ac 'ResolvedMethodVarHandleMethodTypeTableEntryAddress' libj9jit29.so` against the actual compiled library inside the test image returned `0` -- the `J9VM_OPT_METHOD_HANDLE`-guarded block is absent from this build's compiled `messageNames[]` array, so it must be excluded when counting ordinals. Counting from `MessageTypes.hpp` at the pinned commit with that block excluded gives `AOTCache_getROMClassBatch = 231`. This count was validated against three ordinals already independently, empirically confirmed by the sibling findings' own dynamic PoCs (`compilationCode=0`, `getUnloadedClassRangesAndCHTable=7`, `compilationRequest=8`, all of which land correctly), then re-confirmed dynamically by the baseline run below before any boundary-value byte was sent. ## Prerequisites / setup -- what is being stood up, and why This reproduction inverts the usual setup used by the four sibling findings. Get this straight before reading the steps: - The **fake/malicious process is the JITServer** (the "server" role) -- a minimal Python TCP listener, `fake_jitserver.py`, that does not implement the real JITServer wire protocol at all. It only frames/reads the client's first message (to stay byte-aligned on the stream), discards its content, and sends back one hand-crafted reply. - The **real, unmodified `java` binary is the client and the victim** -- a real, officially-built JVM, started with `-XX:+UseJITServer -XX:JITServerAddress=... -XX:JITServerPort=...`, pointed at the fake server above. This JVM does not attack anything; it is attacked. - This is the opposite of findings #940/#941/#943/CHTable-reply, where the real, unmodified `jitserver` binary was the victim and a hand-crafted Python script was the attacking client. Environment, identical to the sibling findings otherwise: - Docker image: `ibm-semeru-runtimes:open-21.0.10_7.1-jdk`, bundled OpenJ9 0.57.0, commit `f0754f410244ad2c42b07c5fe76983a3c7b61e87` (confirmed via `java -version`: `OpenJ9 - f0754f4102`). - Two isolated Docker containers on a fresh user-defined bridge network (`jitclient-net`): - `jitfakesrv` (`python:3-slim`) -- runs `fake_jitserver.py`. - `jitclient-vecwalk` (`ibm-semeru-runtimes:open-21.0.10_7.1-jdk`) -- runs the real, unmodified `java` binary as a JITServer client, pointed at `jitfakesrv` via Docker's embedded DNS. - Workload: `Loop.java`, run with `-Xjit:count=0` (compile every method on first invocation) to force an immediate remote compile attempt, and therefore an immediate server-reply read. - No SSL/TLS configured on either side (default; `CommunicationStream::useSSL()` is false unless JITServer SSL keys/certs are explicitly configured), reproducing the default, unauthenticated wire protocol. ## Steps to reproduce 1. **Start the fake JITServer listener** inside `jitfakesrv`: ``` docker exec jitfakesrv python3 /fake_jitserver.py --listen-port 38500 --mode baseline --timeout 30 ``` {width=900 height=576} 2. **Start the real, unmodified JVM client**, pointed at the fake server, running the `Loop` workload: ``` docker exec jitclient-vecwalk /opt/java/openjdk/bin/java \ -XX:+UseJITServer -XX:JITServerAddress=jitfakesrv -XX:JITServerPort=38500 \ -Xjit:count=0 -cp /tmp Loop ``` The fake server confirms the connection and decodes the client's real, unmodified `compilationRequest` (`type=8, numDataPoints=26`), and the client's own stdout confirms the workload is running. {width=900 height=576} 3. **Baseline / negative control**: the fake server sends a well-formed reply, `type=AOTCache_getROMClassBatch(231)`, field 0 = `EMPTY_VECTOR`. `RawTypeConvert<vector<T>>::onRecv()`'s fast path returns immediately without touching `getNextDescriptor()` -- a completely inert message. The client decodes it, writes back its own well-formed 2-field reply of the same type (exactly matching the source-predicted `AOTCache_getROMClassBatch` handler behaviour), and the whole run exits `0`. {width=900 height=576} 4. **Crash payload**: against a fresh pair of containers, the fake server sends the same message type, but field 0 is now `DataType::VECTOR` wrapping a nested `UINT32` size descriptor declaring **5,000,000** elements, followed by exactly one real, well-formed element descriptor. Total crafted reply: 52 bytes. No further bytes ever arrive back from the client. {width=900 height=576} 5. **Crash evidence**: the real client process dies with SIGSEGV. `R13 = 0x00000000004C4B40 = 5,000,000` decimal is live in a register at the moment of fault, an exact match to the attacker-declared count. The crashing frame is `JITServer::getArgsRaw<std::vector<J9Class*, std::allocator<J9Class*>>>`, called from `handleResponse()` then `handleServerMessage()` -- a byte-for-byte match to the predicted client-side dispatch path for this exact message type. {width=900 height=576} 6. **Client process confirmed crashed**: full JVM dump artifacts (`core`, `javacore`, `Snap`, `jitdump`) are written, and the process exits with code **255**, versus the clean exit `0` of the byte-for-byte-identical baseline run whose only difference was field 0's `DataType`. {width=900 height=576} Reproduction determinism: 1/1 attempt with the baseline reply did not crash the client and produced the exact predicted 2-field echo; 1/1 attempt with the crash payload crashed the client, with the exact declared count captured live in `R13`. ## Relationship to the four sibling findings | | Sibling findings (#940/#941/#943/CHTable-reply) | This finding | |---|---|---| | Who is attacked | The `jitserver` process (network server) | Any real JVM client (`-XX:+UseJITServer`) connecting out | | Who sends the crafted bytes | A TCP client connecting to the JITServer port | The TCP peer the client is configured/pointed at as its JITServer | | Vulnerable function | Same: `RawTypeConvert<std::vector<T>>::onRecv()` / `getNextDescriptor()` | Identical templates -- confirmed both by source and by crash-frame symbol match | | Decode entry point | `ServerStream::readCompileRequest()` / `ServerStream::read<T...>()` | `ClientStream::getRecvData<T...>()`, reached via `ClientStream::read()`, which has **no** expected-type check (unlike `ServerStream::read<T...>()`) | | Message type used | `compilationRequest` (8) / `getUnloadedClassRangesAndCHTable` (7) -- client-to-server | `AOTCache_getROMClassBatch` (231) -- server-to-client | | Reachability | Pre-auth, first bytes of a fresh connection to the JITServer port | Requires the victim to be configured to use (or already be using) the malicious/compromised JITServer; no compile-content trickery needed once connected | | Victim process | `jitserver` (shared, multi-tenant) | The individual client JVM whose workload happened to be mid-compile | The crash stack's innermost frame, `getArgsRaw<std::vector<J9Class*>>`, is a byte-exact match for the predicted instantiation of the `AOTCache_getROMClassBatch` handler's single-field decode, called from `handleResponse()`/`handleServerMessage()` -- functions that exist only in the client-side dispatch code (`JITClientCompilationThread.cpp`), never in the server-side stack traces of the four sibling findings. This is direct, register-and-symbol-level proof of a distinct victim process, a distinct stream class (`ClientStream`, not `ServerStream`), and a distinct message type/direction, not a re-trigger of an already-reported issue. ## Impact A JVM configured with `-XX:+UseJITServer -XX:JITServerAddress=... -XX:JITServerPort=...` trusts whatever host answers on that address/port to behave like a well-formed JITServer. The JITServer protocol has no message-level authentication; TLS, where configured (not the default), only authenticates the TCP endpoint, not each message's shape. If that peer is: - an operator-misconfigured or otherwise untrusted JITServer in a shared/multi-tenant deployment, or - a JITServer that has itself already been compromised via one of the four already-reported server-side pre-auth bugs in this same family, now being used to pivot against the fleet of client JVMs that trust it, then that peer sends a single crafted reply and crashes the connecting client JVM process, with no compilation-content trickery, no multi-round-trip protocol simulation, and no credentials of any kind. Every client JVM configured to use that JITServer is individually crashable, one connection at a time, for as long as the malicious/compromised server keeps answering. No attempt was made to read, print, or characterize any bytes from the out-of-bounds region; this is a bounded crash/DoS reproduction, and no code-execution path is claimed. ## Severity `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H` = **5.9 (Medium)**. This is deliberately not a copy of the sibling findings' server-side vector. The server-side findings are AV:N/AC:L because any anonymous network peer can connect to the public JITServer port and trigger the crash with the very first bytes on the wire -- no precondition outside the attacker's control. This finding requires the attacker to already control, or already have compromised, the specific network endpoint the victim JVM has been configured to trust as its JITServer -- a condition that exists independent of the attacker's own actions at exploit time, which CVSS 3.1 captures as **AC:H**. Once that precondition holds, the rest of the interaction is deterministic and requires no privileges on the victim host (**PR:N**) and no interaction from anyone operating the victim JVM beyond it already running with `-XX:+UseJITServer` configured (**UI:N**), over a normal TCP/IP connection (**AV:N**), with no scope change (**S:U**), no demonstrated confidentiality or integrity impact (**C:N/I:N**), and total, unrecoverable loss of the client JVM process (**A:H**). ## Do you know any mitigations of the issue? Same fix direction as the four sibling findings: bound the loop count in `RawTypeConvert<std::vector<T>>::onRecv()` against the message's actual remaining declared size before iterating, at the single shared template definition, so the fix covers every call site (client and server, every message type) at once rather than patching each individually. Specific to this finding's threat model: `ClientStream::read()` should also validate the received message type against an allow-list of types the client can legitimately receive at that point in the protocol state machine, matching the correlation check `ServerStream::read<T...>()` already performs between the type it asked for and the type it received. This would not fix the underlying unbounded-loop bug by itself, but would materially shrink the set of decode handlers a malicious/compromised JITServer can reach on an unsuspecting client. --- **Attachments:** - [fake_jitserver.py](/uploads/daed906269be063127b6ae1fa1059080/fake_jitserver.py) - [Loop.java](/uploads/1b7db6e1aa7932c743af134ab8404019/Loop.java) - [count_ordinal.py](/uploads/4a9fe60e14bcec21c963d3445d527b99/count_ordinal.py) - [fake_server_baseline_log.txt](/uploads/497970cf6d65ae7a6095a242c80df3a9/fake_server_baseline_log.txt) - [fake_server_crash_log.txt](/uploads/5f4fa3d4831d1c3fc7552b0850d05ee8/fake_server_crash_log.txt) - [crash_client_output.txt](/uploads/647b3ac81e0c4eee175012cdef628686/crash_client_output.txt) - [POC-openj9-jitserver-client-vector-heapwalk-crash.md](/uploads/c43d9ae1c8543ab4c6692d30f6a7056f/POC-openj9-jitserver-client-vector-heapwalk-crash.md) - [ClientStream.hpp](/uploads/a63d157e9521df06ae6fa5456a9572f7/ClientStream.hpp) - [ClientStream.cpp](/uploads/288113232292a5eeae69f867467f4dbc/ClientStream.cpp) - [RawTypeConvert.hpp](/uploads/888e44c3cad239607c74087d47d346eb/RawTypeConvert.hpp) - [JITClientCompilationThread.cpp](/uploads/9af3093663aa48867ec1f3b46faecc32/JITClientCompilationThread.cpp) - [MessageTypes.hpp](/uploads/9382e20390d02ca3e456a08bf40e685f/MessageTypes.hpp)