flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: [BlazeDS] Changed defaults -> increased security
Date Wed, 01 Mar 2017 16:39:31 GMT

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 ;-)


Am 01.03.17, 17:24 schrieb "gkk gb" <modjklist@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.dutz@c-ware.de>
    >     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>"
    >     <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
    >     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

View raw message