Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security Issue: JMX Server Allows Clear Text Authentication - add possibility to disable or secure the JMX interface #293

Open
TerraTalpi opened this issue Jun 20, 2024 · 3 comments
Labels
Milestone

Comments

@TerraTalpi
Copy link

Dear LSC-project team,

the lsc is installed on one of our ubuntu servers and synchronizes some OUs between two LDAP servers. A Qualys Cloud Agent has been installed on most of the servers recently. This agent scans for vulnerabilities, and one vulnerability found (altough only severity 2 out of 5) is being introduced by LSC, because it utilizes JMX without SSL authentication. The possible attack poses the threat, that when remotely connecting to the JMX interface the credentials could be sniffed at the network level. The solution of Qualys proposed is that either the connection is only possible via SSL or from localhost.

We do not utilize JMX via the network (in fact, not at all), therefore I fully understand, that this vulnerability can never be exploited in our case. However it's a running server with a running service that may be exploited in the future by other ways.

I have read the documentation and tried so see how to disable or secure JMX, but it seems that this is currently not implemented / designed for LSC. I have found the following in the lsc-project.org documentation at the documentation for LSC_JMXPORT=1099:

! Warning

But doing such settings, please notice that anyone can send commands to your LSC instance listening on all your network interfaces on the 1099 TCP port ! (At this time this is not a simple task to bind JMX to the local interface only, RFU :)

Therefore, I think a change except for the port of JMX is not yet implemented / designed. I have checked the /etc/default/lsc file and tried to remove the LSC_JMXPORT="1099" instruction and restarted the service, but the JMX is still running.

When I check ps auxf on the system, it returns:

/usr/bin/java -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -cp :.:/usr/lib/lsc/slf4j-api-1.7.31.jar: ...

As far as I understand, this is only enabled in order for the command lsc-agent to work. To start, stop and list jobs and do some other tasks. However, we are not utilizing the this command line interface anyway, so fully disabling JMX would also be a good possibility for us.

Is there already a way that I did not find to achieve this? Either disabling it, or enabling authentication and SSL via a certificate? If not, I'd like to do a request to add the follwing options in the following priority:

  1. Configuration option to disable the JMX interface fully
  2. Configuration option to to set the interface binding of the JMX interface
  3. Configuration option to enable SSL for the connection to JMX
  4. Configuration option to enable authentication for the connection to the JMX interface

A step by step implementation - or just the option to disable it at all - would be awesome in order to remediate this very small but existent security issue.

Maybe the implementation of an option like LSC_JMXENABLED with true and false as possible values is enough, to configure com.sun.management.jmxremote=true/false in the background.

@coudot
Copy link
Member

coudot commented Jun 21, 2024

Set LSC_JMXPORT to empty value.

See https://github.com/lsc-project/lsc/blob/master/bin/lsc#L185

@TerraTalpi
Copy link
Author

Hello @coudot thank you very much for your answer. That fully answers my question, thank you for pointing me to the right code place. I can see that a bash script and a shell script exists to launch lsc via Java. I am pretty familiar with bash and windows batch. If I adapt the code to add support to bind JMX to a specific ip address / interface and also maybe for SSL, would that PR be accepted?

@coudot
Copy link
Member

coudot commented Jun 24, 2024

Yes you can propose this evolution

@coudot coudot added this to the Future milestone Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants