[
https://issues.apache.org/jira/browse/JAMES-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612039#comment-17612039
]
Benoit Tellier commented on JAMES-3829:
---------------------------------------
Note also that FST does aggressive reflection...
{code:java}
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.nustaq.serialization.FSTClazzInfo
(file:/home/interview1/.m2/repository/de/ruedigermoeller/fst/2.57/fst-2.57.jar)
to field java.lang.String.value
WARNING: Please consider reporting this to the maintainers of
org.nustaq.serialization.FSTClazzInfo
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
{code}
Causes issues with Java 17 upward.
> Mailet API: drop Serializable entirely
> --------------------------------------
>
> Key: JAMES-3829
> URL: https://issues.apache.org/jira/browse/JAMES-3829
> Project: James Server
> Issue Type: Improvement
> Components: Mailet Contributions
> Reporter: Benoit Tellier
> Priority: Major
>
> h3. Why ?
> Deserialization attacks is a great classic. An attacker can feed crafted data
> into your deserialization process to execute (given vulnerable class on the
> classpath) arbitrary code.
> Latest exemple: https://security.snyk.io/vuln/SNYK-JAVA-ORGSCALALANG-3032987
> The problem is that the description of "what" is encoded in the payload, and
> blindly followed by the deserializer. Such a genericity comes at a security
> risk.
> Several strategies of defense can be followed:
> - Avoid deserialization, only deserialize to a restrictive, safe, set of
> class.
> - Fix all libraries allowing deserialization related exploit. Which leaves
> exposed to new findings, and can be thought of a cat-and-mouse race.
> We use serialization in a couple of place:
> - JMX CLI that an administrator can turn off
> - The mailet-api allows attribute serialisation. TThis is done through the
> means of the FST serializer that can be used to deserialize any class on the
> classpath and will execute its constructor (I tried!)
> There is no way to turn off FST deserialization.
> The associated surface is limited: an attacker need to be able to craft DB or
> brokers payload: such an access would already be a major threat in itself!
> Yet having uncontrolled serialization in a system as conplex as James leaves
> me thinking... What iff attributeValue serialization is exposed in places I
> did not expect?
> It's also worth mentionning that FST itself is not active for other a year -
> not what I want for security sensitive code.
> Thus I would rather restrict the feature here as by design this would make us
> vulnerable.
> h3. How ?
> Remove completly FST.
> Explain that the user is expected to serialize / deserialize his payloads
> himself.
> Introduce also a way to have "compute only" attributes, with a serializer
> that drops the attribute.
> h3. Inventory
> The following use cases uses FST serialization:
> - Calendar: use a compute only serializer as this is used to cary info
> between 2 mailets.
> - SMIME: put certificates as bytes
> - ProcessorUtil mailet error: use a compute only serializer
> - ActionUtils mailAddress: use a string representation
> h3. Migration
> Recode the FST serializer so that it does nothing. THis way, emails having
> some FST serialized attributes will still be readable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
