Default jdk.serialFilter (JEP-290) for the Java serialization fallback bridge

[L1nq0]

The security documentation already states that topology.fall.back.on.java.serialization must not be enabled in production, precisely because Java native deserialization is vulnerable to arbitrary code execution from untrusted data. This issue suggests one defense-in-depth change that would reduce the impact of that setting being enabled anyway, on Storm 3.0.0.

When topology.fall.back.on.java.serialization is true, KryoTupleDeserializer falls back to a raw ObjectInputStream.readObject() over bytes fully controlled by the sending side (the "Falling back to java serialization" warning).

As defense in depth, the launcher already injects -Djava.deserialization.disabled=true for the daemon JVMs; the same spirit could be extended to this bridge - for example a jdk.serialFilter configured by bin/storm.py for worker JVMs, or a programmatic ObjectInputFilter installed at the fallback bridge - so that a misconfigured cluster degrades to constrained deserialization instead of arbitrary deserialization.

We verified on Temurin 25.0.4 that no jdk.serialFilter is set for workers by default and that the bridge executes readObject callbacks supplied by the stream.

This would leave the documented trust model unchanged and only reduce the impact of operating outside it. Happy to share our reproduction steps or a prototype patch if that would be useful.

[rzo1]

Feel free to provide a PR.

[L1nq0]

Before opening a PR I'd like to align on the design, since there are a few viable shapes that trade differently:

1. Worker-JVM-wide default filter. Add a default -Djdk.serialFilter=<deny-list of known gadget packages> to worker.childopts in conf/defaults.yaml. Zero Java code (a JVM-wide filter applies to every ObjectInputStream in the worker, including the fallback bridge), and it also covers the other native deserialization points in the worker (worker hooks, custom stream groupings, thrift-serialized component objects). Downsides: it changes default behavior for every deployment on upgrade; sites that override worker.childopts wholesale silently lose it; a gadget deny-list is a permanent maintenance surface; and it risks reading as "the fallback is now safe enough", which the security docs rightly push back on.
2. Bridge-scoped programmatic ObjectInputFilter. Install a filter in SerializableSerializer.read (where the fallback performs a raw ObjectInputStream.readObject()), driven by a new config key, default empty (opt-in). Precise scope (exactly the documented-risky data path), no global default change, and it also covers LocalCluster, where worker.childopts never applies.
3. Docs-only recipe. No code; add a security-docs recipe for "if you must run with the fallback, configure jdk.serialFilter like this". Zero behavior change, but no default protection.

My lean is (2) with an empty default: it adds a precise, explicit control exactly where the docs already warn, changes no default behavior, and keeps the security message intact (the fallback stays discouraged; if you must run it, here is a filter). I'd pair it with the docs recipe from (3). (1) works too if you prefer the JVM-wide defense-in-depth angle.

One scoping note from looking at this: besides the fallback bridge, the worker JVM deserializes native objects at a few other points (worker hooks, custom stream groupings, trident bolts, thrift-serialized component objects) — all fed by topology-defined, submitter-supplied bytes rather than runtime data. A JVM-wide filter would cover those too, which is the main argument for (1).

Which of these fits Storm best — or if none of them does, what direction would you take? Once we agree I'll put up the PR.

[rzo1]

Ping @GGraziadei :)

[GGraziadei]

Hi, thanks for reporting

[L1nq0]

Following up on the design alignment: I've put up #9075 implementing option (2)'s mechanism — bridge-scoped programmatic filter, config-key driven — but shipping it with the deny-list default rather than empty. Reasoning in the PR description; the short version: the knob exists exactly because this path is dangerous by default, so the default should constrain it, and the empty-default escape hatch is one config line for anyone who needs the old behavior. If you prefer strict option (2), say the word and I'll drop the defaults.yaml line — no code change needed.