L1nq0 opened a new issue, #9073: URL: https://github.com/apache/storm/issues/9073
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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
