[ 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: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org