Hello,
Yes correct. This is also partly the intent (but mostly this is
"security reasons")
https://www.mail-archive.com/server-user@james.apache.org/msg16698.html .
Regards,
Benoit
On 04/05/2023 04:47, Wojtek wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
