[
https://issues.apache.org/jira/browse/CAMEL-24509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino resolved CAMEL-24509.
--------------------------------------
Resolution: Fixed
> camel-mina - gate the exchange-holder unmarshal on transferExchange and mark
> objectCodecPattern as security-relevant
> --------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24509
> URL: https://issues.apache.org/jira/browse/CAMEL-24509
> Project: Camel
> Issue Type: Bug
> Components: camel-mina
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.23.0
>
>
> Two related hardening items in camel-mina's object-codec path.
> *1. The exchange-holder unmarshal is not gated on {{transferExchange}}*
> {{MinaPayloadHelper.setIn()}} / {{setOut()}} unmarshal an inbound
> {{DefaultExchangeHolder}} whenever the decoded object happens to be one, with
> no check that the endpoint enabled {{transferExchange}}:
> {code:java}
> public static void setIn(Exchange exchange, Object payload) {
> if (payload instanceof DefaultExchangeHolder) {
> DefaultExchangeHolder.unmarshal(exchange, (DefaultExchangeHolder)
> payload);
> {code}
> {{DefaultExchangeHolder.unmarshal()}} rebuilds the whole Exchange from the
> payload - exchange id, in body, in headers (via {{setHeaders}}, which
> replaces the map wholesale, including the {{MINA_*}} headers the consumer set
> moments earlier), the out message, and every exchange property.
> The equivalent path in camel-jms is gated: {{JmsBinding}} checks
> {{isObjectMessageEnabled()}} and calls {{checkDeserializedClass(payload)}}
> before it will unmarshal a holder. camel-mina has neither check.
> *Reachability is limited, and this is defence in depth rather than a
> reachable hole.* The object codec's accept-list refuses an arbitrary class
> when {{objectCodecPattern}} is unset, which is the default - verified against
> mina-core 2.2.4, where a {{String}} decodes but a {{HashMap}} or a
> {{DefaultExchangeHolder}} raises {{ClassNotFoundException}}. Reaching the
> helper with a holder therefore requires the operator to have widened
> {{objectCodecPattern}} first.
> Proposal: gate the unmarshal on the endpoint's {{transferExchange}} setting,
> so a decoded holder is treated as an ordinary body unless the endpoint asked
> for exchange transfer. This matches camel-jms and leaves documented
> {{transferExchange=true}} deployments working.
> *2. {{objectCodecPattern}} is not marked as a security-relevant option*
> The option widens the deserialization allow-list but carries no {{security}}
> marker, unlike {{transferExchange}} on the same configuration class, which is
> annotated {{security = "insecure:serialization"}}. Its description also does
> not warn about {{*}}, while three historical upgrade guides (4.4, 4.8, 4.10)
> tell readers "You can use {{*}} to accept all patterns".
> Proposal: mark the option {{security = "insecure:serialization"}} and extend
> its description to say that the pattern should be as narrow as the route
> needs, that {{*}} accepts every loadable class from an untrusted peer, and
> that leaving it unset is the safest choice. The historical upgrade guides are
> release history and are left as-is.
> Present on {{main}}, {{camel-4.22.x}} and {{camel-4.18.x}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)