[
https://issues.apache.org/jira/browse/CAMEL-24676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18114114#comment-18114114
]
Claus Ibsen commented on CAMEL-24676:
-------------------------------------
Backported to the supported LTS lines:
* camel-4.22.x: https://github.com/apache/camel/pull/26281 (merged as
da07367d1b6e)
* camel-4.18.x: https://github.com/apache/camel/pull/26283 (merged as
f988494d0114)
The 4.18.x port is not a straight cherry-pick: core/camel-support has no
DeserializationFilterHelper on that branch, so the filter resolution, the
default pattern constant and the class-only FilterInfo are implemented locally
in JGroupsEndpoint, matching the component-local style
JmsBinding/MinaConverter/NettyHttpHelper already use there. The default pattern
is identical to the shared helper DEFAULT_CLASS_DESERIALIZATION_FILTER.
_Claude Code on behalf of davsclaus_
> camel-jgroups: add a configurable deserialization filter and document
> serialization hardening for the consumer
> --------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24676
> URL: https://issues.apache.org/jira/browse/CAMEL-24676
> Project: Camel
> Issue Type: Improvement
> Components: camel-jgroups
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.18.5, 4.22.1, 4.23.0
>
>
> The camel-jgroups consumer maps an incoming cluster message to the exchange
> body by calling {{org.jgroups.Message.getObject()}}, which returns the Java
> object carried by the message ({{JGroupsEndpoint.createExchange(Message)}}).
> Unlike the other Camel components that can receive Java-serialized payloads
> (the camel-netty and camel-mina object codecs, camel-jms
> {{objectMessageEnabled}}, camel-spring-redis), camel-jgroups currently
> exposes no way to constrain the types it accepts from the cluster, and its
> documentation does not describe the serialization trust boundary of a JGroups
> cluster.
> This is a consistency / hardening task to bring camel-jgroups in line with
> the shared deserialization-filter work:
> * Add a configurable {{deserializationFilter}} option on the
> consumer/component, resolved through the shared
> {{org.apache.camel.support.DeserializationFilterHelper}} (CAMEL-23815 /
> CAMEL-24296), so an application can restrict the classes accepted from the
> cluster to an allow-list.
> * Apply the resolved filter as a class check on the message body before it is
> routed downstream.
> * Add a Security section to the camel-jgroups component documentation
> explaining that message bodies are Java-deserialized, that the default
> protocol stack does not authenticate peers, and recommending the effective
> hardening levers: a JVM-wide {{jdk.serialFilter}}, and configuring the
> {{JChannel}} with authentication ({{AUTH}}) and encryption ({{SYM_ENCRYPT}} /
> {{ASYM_ENCRYPT}}) via {{channelProperties}}.
> Note: JGroups performs object deserialization inside its own receive path, so
> the JVM-wide {{jdk.serialFilter}} together with channel-level authentication
> and encryption are the primary mitigations. The component-level
> {{deserializationFilter}} is a defense-in-depth allow-list for the message
> body and is documented as such.
> Related hardening: CAMEL-24296, CAMEL-24370, CAMEL-24421, CAMEL-24509.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)