Serialization and security

[Simon]

Hi guys,

as you may be aware the security community is currently discussing the merits of serialization, e.g.:

http://de.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles

TL;DR: ctors can be evil, too, especially when invoked through deserialization.

Now I have no clue if that actually applies to the ceylon serialization, but from a quick glimpse it seems like "it doesn't care". Granted, ceylon may have limited exposure due to the modules approach, but I suggest to check for this now that you're (probably) working on a bugfix release, if you haven't already done so.

There is a "danger" that you'll say that the actual deserialization library has to take care of that. Well, that is somehow right but IMO fosters negligence. It would be far better it the deserialization context would enforce, or help enforce, stricter boundaries.

By stricter I mean stricter than "whitelisted by some annotation" because the very problem at the root of all this it the amount of trust you can have towards all of your library authors. Normally that's just above zero, but unconstrained deserialization actually requires a fair amount of  trust.

Unfortunately I don't have the time to work on it, but I thought I'd at least put it up for you to decide whether or how to act on it.

Thanks,

Simon

[Tom Bentley]

That's quite interesting, thanks.

There are a number of ways this applies to Ceylon:

* On the JVM all modules have access to the whole of the Java APIs at runtime, because there's just one system classloader. I'm not sure there's much we can do about that (right now, at least, maybe java 9 will help).

* Jboss modules' classloader isolation should help somewhat with exploits that rely on using (non-JDK) dependencies.

* The situation is worse on other VMs

* The serialization API (ceylon.language.serialization) doesn't concern itself with formats, nor applications, so I'm not sure any of the suggested mitigations really apply directly to it.

* Serialization libraries could chose to support some of the suggested mitigations. For example whitelisting of serializable classes could be easily supported at the serialization library level. Unfortunately it relies on the application programmer to know (and bother to enumerate) the classes in the whitelist.

* The onus will always be on the application developer not to do stupid things (like putting serialized objects in a cookie). Unfortunately people (developers included) do stupid things anyway. The best we can do there is simply education.

* Finally, on the JVM many Ceylon classes are java.io.Serializable. Since the particular vectors described in the link rely on having serializable gadgets, I suppose that makes it easier for an adversary to find susceptible gadgets. But I guess if you're using Java serialization you're prepared to apply the Java mitigations such as subclassing ObjectInputStream.

Cheers,

Tom

--
You received this message because you are subscribed to the Google Groups "ceylon-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-dev+...@googlegroups.com.
To post to this group, send email to ceylo...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/9936b017-8a3f-42aa-8804-1a8cf5d3930e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gavin King]

Doesn't *our* serialization API already work by whitelisting, i.e. the
"serializable" annotation?

> https://groups.google.com/d/msgid/ceylon-dev/CAMd5Yswrcp4wNAZ_-EpwTtDJutWgu8CUHSA3%3D9YzEi_NdRvDNQ%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.

--
Gavin King
ga...@ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org

[Tom Bentley]

Well, yes. But that still means that any class that's marked as "serializable" can be included in any serialization. The sort of whitelisting I was referring to is one where the deserializing client knows it's expecting a certain kind of graph and can enumerate the classes (or packages or modules) of the instances allowed in that particular graph. So much more fine grained.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAP7PoCf5WZf8k2aLFeSfL_SDRKX0UyPjOvbOQSX1DMxvmGhuEg%40mail.gmail.com.

[Simon]

Yes, but that's not enough. The attack vectors presented in the slides exploit Apache Commons Collection - all that is needed is any one vulnerable library you are using or one of your dependencies is using.

That is the crack to fill - you anticipate some set of classes, but deserialization could reach any code in reach of yours where some lost soul puts exec() in their serializable class ctor. It is unrealistic to check against that, and even if you did you'd have to repeat it for virtually every update.

The flaw is the ultimate trust towards ALL your code required by semi-trusted(*) deserialization. The only thing you can really do is lower the attack surface, e.g. by letting the programmer specify which classes/packages may be deserialized from a given stream (i.e. white/greylisting).

My point is: The easier whitelisting is to the programmer, the more likely is it to be used before, not after the fact. Plus, for ceylon, now is a good time to fix it.

(*) I do not believe in the existence of a "semi-trusted" class of data but many do, depending in unhealthy ways on deadlines and security culture.

Cheers,

Simon

[Simon]

Tom, thanks for the analysis.

FTR, I disagree with the notion that the best you can do is simply education. The serialization API could provide a credible wite/greylisting implementation, perhaps associated to the serialization context, so the API would help you and the actual library not deserializing and, for consistency, serializing unintended classes. This would also have utility to really pin down serialization-based APIs. You could even sell this as a feature that helps define proper APIs and/or forward/backward compatibility, and has the negligible side-effect of being more secure.

Let me add that, as someone who did extend ObjectInputStream, this is a disheartening exercise. I don't think someone will do it unless forced to.

Cheers,

Simon

[Simon]

One more: Jboss marshalling does sell this as a feature.

http://jbossmarshalling.jboss.org/

[Tom Bentley]

Hi Simon,

You're right that the API of ceylon.language.serialization *could* support some kind of whitelisting, but usually between that API and the client that's actually got some objects to serialize is the serialization library, with it's own API, and it's this API that the client will usually deal with. So the serialization library would have to make use of the ceylon.language.serialization facility and offer its own API for it to clients. So there's a small benefit to having it ceylon.language.serialization, but it's nothing that the serialization library couldn't do just as effectively on its own. So I'm not opposed to the idea of doing this in ceylon.language.serialization, I'm just not convinced it helps *significantly*.

Cheers,

Tom

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/80677233-83ad-4689-a94b-3fd8671512ad%40googlegroups.com.

[John Vasileff]

> On Nov 26, 2015, at 4:43 AM, Tom Bentley <t.j.b...@gmail.com> wrote:
>
> * The onus will always be on the application developer not to do stupid things (like putting serialized objects in a cookie). Unfortunately people (developers included) do stupid things anyway. The best we can do there is simply education.
>

Do you mean without whitelisting, or in general? What are the intended use cases for the serialization library?

John

[Tom Bentley]

The point I was trying to make was that, in general, it's impossible from preventing people from doing daft things. In this case it doesn't matter what security features we build into whatever we write, some users will manage to not use them.

--
You received this message because you are subscribed to the Google Groups "ceylon-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-dev+...@googlegroups.com.
To post to this group, send email to ceylo...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/21B14731-3E04-482E-937D-6B0C4D79AB1D%40vasileff.com.

[John Vasileff]

Sure, but knowing very little about the new serialization stuff, I'm curious about its intended uses, regardless at what layer security protections might be added.

In any event, interesting thread!

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAMd5YswnVgBQ1BJVReQSR4zy22y9a7Tn96DFGQSKC4VQ8WnWRA%40mail.gmail.com.

[Simon]

Hi!

So, one case that would make a difference is a typical web service offering read/write of mostly the same stuff over xml, json and maybe some binary thing for performance. That's 3 libraries which each requires its own approach to securing it at this very basic level. A platform option would help here AND raise awareness.

Considering the "onus" you mentioned and where it is, I'd say, it's currently on the libaries and individual programmers precisely because the platforms have failed. Quite spectacularly, I'd say. And ceylon is in the right position, at the right time, to do better.

As has been shown, open deserialization is much like the infamous eval(). I can only encourage you to also view it as a platform duty - and opportunity - to offer better options (like JSON.parse did).

Cheers!

[Tom Bentley]

See https://github.com/ceylon/ceylon/issues/5891

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/60fffc58-3097-4e9a-a36b-7eb25c014dea%40googlegroups.com.