<div dir="ltr"><div>After talking with Emond the derialization is only possible for authenticated users. Because we have transparent local auth for users running under the same user as the server if you test from if you test locally it can give different results to what an actual remote user could see. <br><br></div><div>There is no way around this for authenticated users, protocols such as remote EJB rely on serialization to send their data. Even then if you have a malicious authenticated user modular class loading should prevent exploitation of the commons-collections problem unless the deployment depends on (or includes) common-collections.<br></div><div><br></div>Stuart<br><div><br><br><div><br><div class="gmail_quote"><div dir="ltr">On Tue, 10 Nov 2015 at 21:06 Stuart Douglas <<a href="mailto:stuart.w.douglas@gmail.com">stuart.w.douglas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Can you send me the details? <br><br>I don't think we are actually vulnerable to the commons attack out of the box, modular class loading provides a very effective barrier against these kind of attacks. There are only a few modules that reference commons-collections, and they are not in any way involved with remote communication. <br><br></div></div><div dir="ltr"><div>Stuart<br></div></div><div dir="ltr"><div><br><br></div><div><div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, 10 Nov 2015 at 19:31 Emond Papegaaij <<a href="mailto:emond.papegaaij@topicus.nl" target="_blank">emond.papegaaij@topicus.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
As you probably know, there has recently been quite some discussion about<br>
remotely exploitable attacks via deserialization, for instance [1] and [2].<br>
These exploits are demonstrated against commons-collections 3 and 4, spring 4<br>
and groovy 2.4.4, but it is very likely other libraries (if not the jdk<br>
itself) also contain vulnerable code. In general, the advise is to not accept<br>
any serialized objects on a public interface.<br>
<br>
WildFly multiplexes its remote EJB invocation over the http port via http-<br>
remoting. I've found a way to make a WilfFly instance, configured with the<br>
default standalone.xml, accept arbitrary serialized objects. Access to port<br>
8080 is all you need. I've been able to verify the commons-collections exploit<br>
by adding commons-collections to the right module and let WildFly deserialize<br>
my objects. So far, I've not been able to exploit WildFly using only the<br>
classes available via this route, but I've got the feeling that this is only a<br>
matter of time.<br>
<br>
As this is potentially sensitive information, I'm looking for a less public<br>
channel to share the details.<br>
<br>
Best regards,<br>
Emond Papegaaij<br>
<br>
<br>
[1] <a href="http://www.infoq.com/news/2015/11/commons-exploit" rel="noreferrer" target="_blank">http://www.infoq.com/news/2015/11/commons-exploit</a><br>
[2] <a href="http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability" rel="noreferrer" target="_blank">http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability</a><br>
<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</blockquote></div></div></div></div></div></blockquote></div></div></div></div>