[jira] [Created] (JAMES-3829) Mailet API: drop Serializable entirely

["Benoit Tellier (Jira)" <se...@james.apache.org>]

Benoit Tellier created JAMES-3829:
-------------------------------------

             Summary: 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


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