You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by Christofer Dutz <ch...@c-ware.de> on 2017/03/01 09:04:57 UTC
[BlazeDS] Changed defaults -> increased security
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
Re: [BlazeDS] Changed defaults -> increased security
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <mo...@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 <ch...@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
>
Re: [BlazeDS] Changed defaults -> increased security
Posted by gkk gb <mo...@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 <ch...@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
>
Re: [BlazeDS] Changed defaults -> increased security
Posted by gkk gb <mo...@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 <ch...@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
>