[
https://issues.apache.org/jira/browse/JAMES-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612038#comment-17612038
]
Benoit Tellier commented on JAMES-3829:
---------------------------------------
Given the following objects ...
{code:java}
private static class Vulnerable implements java.io.Serializable {
private final Runnable runnable;
public Vulnerable(Runnable runnable) {
runnable.run();
this.runnable = runnable;
}
}
{code}
(note do not do this! this is typical of deserialization vulnerabilities...)
{code:java}
public static class MessagePrinter implements Runnable, Serializable {
private final String msg;
public MessagePrinter(String msg) {
this.msg = msg;
}
@Override
public void run() {
System.out.println(msg);
}
}
{code}
A sample runnable that is serializable.
Resulting format:
{code:java}
{
"serializer": "FSTSerializer",
"value": {
"typ": "org.apache.mailet.AttributeValueTest$Vulnerable",
"obj": {
"runnable": {
"typ":
"org.apache.mailet.AttributeValueTest$MessagePrinter",
"obj": {
"msg": "pwnd"
}
}
}
}
}
{code}
Then as an attacker, I need to find a Runnable doing something interesting and
that happens to be serializable and I win...
Deserializing this prints ...
{code:java}
pwnd
{code}
> 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
