Does this mean that it should be possible (well, easier) to migrate to Jave17 and newer given one of
the biggest obstacles (FST) is gone?
Wojtek
On 02/05/2023 23:24, Benoit Tellier (Jira) wrote:
[
https://issues.apache.org/jira/browse/JAMES-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3829.
---------------------------------
Fix Version/s: 3.8.0
Resolution: Fixed
Now user should adapt their code in order to serialize their payloads as bytes
by themselves.
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
Fix For: 3.8.0
Time Spent: 10m
Remaining Estimate: 0h
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
