It was found that a flaw in commons-collection library allowed remote code execution wherever deserialization occurs. While JBoss doesnt expose the JMXInvokerServlet by default, other interfaces where deserialization occur might be vulnerable.
Note: classes directly referenced by this flaw: InvokerTransformer, InstantiateFactory, and InstantiateTransformer
External References:
http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ https://access.redhat.com/solutions/2045023
An improper input sanitization flaw was found in the way JBoss Seam web application framework processed certain parametrized JBoss Expression Language expressions. A remote attacker could use this flaw to execute arbitrary code via a URL, containing appended, specially-crafted expression language parameters, provided to certain applications based on the JBoss Seam framework. Note: A properly configured and enabled Java Security Manager would prevent exploitation of this flaw.
References: [1] http://seamframework.org/ [2] http://docs.jboss.org/seam/2.2.0.GA/en-US/html/elenhancements.html
Acknowledgements:
Red Hat would like to thank Meder Kydyraliev of Google Security Team for responsibly reporting this issue.
The Web Console (aka web-console) in JBossAs in Red Hat JBoss Enterprise Application Platform (aka JBoss EAP or JBEAP) 4.2 before 4.2.0.CP09 and 4.3 before 4.3.0.CP08 performs access control only for the GET and POST methods, which allows remote attackers to obtain sensitive information via an unspecified request that uses a different method.
The drools serialization format allows to embed class files. Upon deserialization those are loaded by the VM that runs the drools engine. If that (attacker-controlled) class files defines code in a static initializer it is executed during deserialization.
A flaw was found in JBoss Enterprise Application Platform. The processInvocation function within the org.jboss.as.ejb3.security.AuthorizationInterceptor component incorrectly authorizes all requests when no roles are defined for an Enterprise Java Beans (EJB) method invocation. This allows attackers to bypass intended access restrictions for EJB methods, leading to unauthorized access to sensitive functionalities.
By using a specially crafted HTTP request, the authentication of the jmx-console can be bypassed, as the access restrictions only apply for GET and POST.
Current setting is:
<security-constraint> <web-resource-collection> <web-resource-name>HtmlAdaptor</web-resource-name> <description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application </description> <url-pattern>/</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>JBossAdmin</role-name> </auth-constraint> </security-constraint>
and should be changed to block ALL http-methods.
Acknowledgements:
Red Hat would like to thank Stefano Di Paola and Giorgio Fedon of Minded Security for responsibly reporting this issue.
Red Hat JBoss Enterprise Application Platform (aka JBoss EAP or JBEAP) 4.2 before 4.2.0.CP09 and 4.3 before 4.3.0.CP08 allows remote attackers to obtain sensitive information about "deployed web contexts" via a request to the status servlet, as demonstrated by a full=true query string. NOTE: this issue exists because of a CVE-2008-3273 regression.