Hi,
Unfortunately, I can’t ;-)
In general, any class that is Externalizable could do bad things. Which classes
are available on your class path, depends on your application.
Assuming there was a class in any library you have which implements the
Externalizable interface in a way that it formats you hard-drive. Just having
that class in your class path would be enough to be vulnerable. All an attacker
would have to do, was to send a message to BlazeDS in which it sends an object
of that type, as soon as BlazeDS would start deserializing that class, it would
wipe your hard-drive. Even if this might be a little exaggerated example, just
think about the Apache Commons “vulnerability” causing trouble last year. This
wasn’t because of a problem of Apache Commons, it just contained a class which
you could to dangerous stuff with, when giving it well prepared property values.
We were lucky that BlazeDS wasn’t vulnerable to that as I think the constructor
required arguments (lucky us) … but I keep on seeing similar attacks and I
would like to pre-emptively be on the safe side here.
I hope you see how powerful this type of attack could be. That’s why we decided
to turn up the security a little ;-)
Chris
Am 01.03.17, 17:24 schrieb "gkk gb" <modjkl...@comcast.net>:
Thanks Chris, Can you describe the symptoms of a deserialization attack, so
I know the problem this is solving? (e.g. how would I know if it affects my
app?)
>
> On March 1, 2017 at 1:04 AM Christofer Dutz
<christofer.d...@c-ware.de> wrote:
>
> Hi guys,
>
> I just wanted to inform you that a few days ago I added some changes
to BlazeDS.
>
> What I did – besides some cleaning up – was to change some of the
defaults used by an out-of-the-box BlazeDS instance.
>
> Being the one maintaining BlazeDS I always got a little nervous when
reading about some deserialization problem in other projects. Usually I checked
if BlazeDS would be affected by the same problem. In the past usually BlazeDS
wasn’t, as it has a quite unique way of handling deserialization. But my
continued paranoia on this topic made me realize that we should change some of
the default settings:
>
> * First off … I disabled the deserialization of XML per default
>
> * Second I enabled the ClassDeserializationValidator to only
allow the deserialization of well-known classes (Whitelisting)
>
> The first change was due to the fact, that most of the problems we
had in the past were related to XML deserialization as this uses javas default
implementation and that is very powerful but also a good attack vector in
general. In most projects, I use BlazeDS in I never pass XML objects via AMF.
So, if you need to do this, you need to manually enable XML deserialization in
the channel definition by:
>
> <channels>
> <channel-definition id="amf" class="mx.messaging.channels.AMFChannel">
> <endpoint url="Fehler! Linkverweis
ungültig.<http://%7bserver.name%7d:%7bserver.port%7d/%7bcontext.root%7d/messagebroker/amf>"
class="flex.messaging.endpoints.AMFEndpoint"/>
> <properties>
> <serialization>
> <allow-xml>true</allow-xml>
> </serialization>
> </properties>
> </channel-definition>
> </channels>
>
> Second was my experience that if you setup a BlazeDS server you
usually know which classes are passed over the wire. Therefore per default, all
custom classes will be denied unless you explicitly allow them (patterns
allowed).
>
> Here I didn’t change anything with the validator, I just enabled it
per default and revised the Whitelist.
>
> I the services-config.xml you can define the allowed classes like
this:
>
> <validators>
> <validator
class="flex.messaging.validators.ClassDeserializationValidator">
> <properties>
> <allow-classes>
> <class name="org.dukecon.*"/>
> <class name="flex.messaging.messages.*"/>
> <class name="flex.messaging.io.amf.ASObject"/>
> </allow-classes>
> </properties>
> </validator>
> </validators>
>
> We have defined a whitelist which is used per default and have
checked that with several applications. I would like to ask you to check if
this whitelist is missing important entries.
>
> Right now, we have these classes listed:
> "flex.messaging.io.amf.ASObject",
> "flex.messaging.io.amf.SerializedObject",
> "flex.messaging.io.ArrayCollection",
> "flex.messaging.io.ArrayList",
> "flex.messaging.messages.AcknowledgeMessage",
> "flex.messaging.messages.AcknowledgeMessageExt",
> "flex.messaging.messages.AsyncMessage",
> "flex.messaging.messages.AsyncMessageExt",
> "flex.messaging.messages.CommandMessage",
> "flex.messaging.messages.CommandMessageExt",
> "flex.messaging.messages.ErrorMessage",
> "flex.messaging.messages.HTTPMessage",
> "flex.messaging.messages.RemotingMessage",
> "flex.messaging.messages.SOAPMessage",
> "java.io.Externalizable",
> "java.lang.Boolean",
> "java.lang.Byte",
> "java.lang.Character",
> "java.lang.Double",
> "java.lang.Float",
> "java.lang.Integer",
> "java.lang.Long",
> "java.lang.Object",
> "java.lang.Short",
> "java.lang.String",
> "java.util.ArrayList",
> "java.util.Date",
> "java.util.HashMap",
> "org.w3c.dom.Document",
>
> With these changes, we should be safe against most of the
deserialization attacks now and in the future.
>
> Feedback highly appreciated.
>
> Chris
>
