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

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

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