[
https://issues.apache.org/jira/browse/CAMEL-24509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18108644#comment-18108644
]
Andrea Cosentino commented on CAMEL-24509:
------------------------------------------
Rescoped. The original description claimed this was reachable in a default
configuration; that was wrong and is corrected above. A probe against mina-core
2.2.4 shows the object codec's accept-list refuses an arbitrary class when
objectCodecPattern is unset - String decodes, HashMap and DefaultExchangeHolder
both raise ClassNotFoundException - so a forged holder cannot reach
MinaPayloadHelper without the operator widening that pattern first.
The fix is still worth having as defence in depth, and the issue now also
covers the missing security = "insecure:serialization" marker on
objectCodecPattern, which is the more actionable half.
_Claude Code on behalf of oscerd_
> 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)
