Does CVE-2014-3518 affect JBoss products?
Environment
- Red Hat JBoss Enterprise Application Platform (EAP)
- 5.x
- Red Hat JBoss BRMS (BRMS)
- 5.x
- Red Hat JBoss SOA Platform (SOA-P)
- 5.x
- Red Hat JBoss Portal (JPP)
- 5.x
Issue
-
JBoss Application Server 5 and supported Red Hat JBoss 5.x products contain JBoss Remoting, which includes a partial implementation of the JMX remoting specification JSR 160.
-
This implementation is provided in
jmx-remoting.sar
, which is deployed by default in unsupported community releases of JBoss Application Server 5.x. This implementation does not implement security as defined inJSR 160
, and therefore does not apply any authentication or authorization constraints. A remote attacker could use this to potentially execute malicious code on a vulnerable server. This flaw is identified by CVE-2014-3518. -
Does this affect Jboss Products?
-
Does the JBoss Remoting Vulnerability CVE-2014-3518 affect Red Hat JBoss EAP 5 if the
jmx-remoting.sar
is not deployed in the Jboss instance? -
Is the vulnerability
CVE-2014-3518
specifically related to the Mail service? - Multiple Red Hat JBoss Products Remote Arbitrary Code Execution Vulnerability. RedHat
CVE-2014-3518
reported. Kindly suggest.
Resolution
-
By default, all supported Red Hat JBoss 5.x products are not affected. These products will only be vulnerable if JMX remoting is enabled by manually deploying
jmx-remoting.sar
from thejboss-as/docs/examples
directory. Unsupported community releases of JBoss Application Server 5.x are affected by default. All users of the standalone JBoss Remoting project are also affected. -
If your server is affected, you should undeploy
jmx-remoting.sar
if JMX remoting is not required by your applications. If it is required, you should secure JMX remoting.
Configuring with password access files security
# Enable the jconsole agent locally
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote"
# Tell JBossAS to use the platform MBean server
JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
# Make the platform MBean server able to work with JBossAS MBeans
JAVA_OPTS="$JAVA_OPTS -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"
# Set the port
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=19988"
# Enable security using user/pass in properties file
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.password.file=$JBOSS_HOME/bin/jmxremote.password -Dcom.sun.management.jmxremote.access.file=$JBOSS_HOME/bin/jmxremote.access"
-
Unless it is set,
com.sun.management.jmxremote.access.file
defaults to$JAVA_HOME/jre/lib/management/jmxremote.access
andcom.sun.management.jmxremote.password.file
defaults to$JAVA_HOME/jre/lib/management/jmxremote.password
-
The usernames and passwords are defined in
jmxremote.password
(there is a template in$JAVA_HOME/jre/lib/management/jmxremote.password.template
) -
For example, adding an admin user with a password of redhat, and a user named monitor with password jboss, would be like:
admin redhat
monitor jboss
- The users's roles are defined in jmxremote.access, there are two roles readonly and readwrite, so we could allow user monitor to only read mbeans and allow user admin to read and write by:
admin readwrite
monitor readonly
- Then test the service connectivity: jmx:rmi:///jndi/rmi://127.0.0.1:19988/jmxrmi
import javax.management.MBeanServerConnection;
import javax.management.remote.JMXServiceURL;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import java.util.Map;
import java.util.HashMap;
// this is the port that you configure in $JBOSS_HOME/bin/run.conf
int portNum = 19988;
// the hostName should be set to the ip / hostname that the JBoss you want to call is listening upon
String serviceURL = "service:jmx:rmi:///jndi/rmi://" + hostName + ":" + portNum + "/jmxrmi";
// Create a JMXServiceURL
JMXServiceURL u = new JMXServiceURL(serviceURL);
// If you have authentication enabled, configure the username / password credentials
Map environment = new HashMap(1);
String[] credentials = {user, pass};
environment.put(JMXConnector.CREDENTIALS, credentials);
// connect to the JMXServiceURL using the given environment properties (If you have authentication disabled, you can remove the environment)
JMXConnector c = JMXConnectorFactory.connect(u, environment);
// Get the MBeanServer connection which has the API to get and call the MBeans
MBeanServerConnection server = c.getMBeanServerConnection();
// Test by getting the number of mbeans
System.out.println("MBean Count: " + server.getMBeanCount());
// Cleanup
if(c != null) {
c.close();
}
Diagnostic Steps
- To determine whether your system is vulnerable, use the Red Hat access labs detector tool.
If you havejmx-remoting.sar
enabled and affected, you should see some lines printed out like this:1
$ java -jar CVE-2014-3518-SAFE.jar -H 127.0.0.1 -r 19988
[CVE-2014-3518] Testing RMI via remote connections ...
[CVE-2014-3518] Testing with host::127.0.0.1 rmi-port::19988
[CVE-2014-3518]
[CVE-2014-3518] Testing mail service ...
[CVE-2014-3518] jboss:service=Mail.getJNDIName returned java:/Mail
[CVE-2014-3518] MailService returned as expected, VULNERABLE
- By default on JBoss EAP 5.x, if
jmx-remoting.sar
is not configured, you will see:
$ java -jar CVE-2014-3518-SAFE.jar -H 127.0.0.1 -r 1090
[CVE-2014-3518] Testing RMI via remote connections ...
[CVE-2014-3518] Testing with host::127.0.0.1 rmi-port::1090
[CVE-2014-3518] RMI Server returned unknown host, poisoning cache to try again ...
[CVE-2014-3518] Could not make an RMI connection, skipping. Reason: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is:
java.net.ConnectException: Connection refused]
-
Using the JBoss Remoting implementation as provided within the
jmx-remoting.sar
, or any implementation that was based on thoseJARs
, is affected by this vulnerability. The mail service, which is tested byCVE-2014-3518-SAFE.jar
above, is just one of many services that could be used by an unauthenticated attacker, circumventing any other security. ↩︎
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Comments