Misconfiguration of Java web server component Jolokia puts orgs at risk Misconfiguration of a commonly used Java web server component puts websites at risk of attack, web dev and security researcher Mat Mannion has warned. Shortcomings in Jolokia's Java Management Extensions (JMX) open the door to information disclosure, denial of service, and other potential attacks against Java web servers. The …
Java 1.2 and JSP (JavaServerPages) was good, but then came all these bloat (XML, EE, ...).
I am avoiding Java on Server since 2002. (And on desktop only for Minecraft 1.8 and Intelli Web/PHPStorm IDE)
Though I hate that Apache foundation (and Yahoo) for hoping on the Java bandwagon so late (~2005) in the game and invested so much dev time to Lucene and its sibling-abortions (Hadoop, Solr, Nutch, Cassandra, Spark, HBase, Kafka, UIMA, ZooKeeper, OpenNLP, ActiveMQ and what not). Drop the Java-Lucene and focus on Go or C++ Lucene port! And the other Apache projects that all rely on Lucene will follow.
Only the older proper coded Apache HTTP Server and Apache Traffic Server are in sane C and C++.
Could you please elaborate a bit to which Jolokia security flaws are you referring to? I'm not aware of any outstanding issue, but happy to fix them where I can.
I completely back your statement that you have to harden Jolokia for production use, as the JMX subsystem gives you superpowers over your server. Rule Nr. 1: Don't expose Jolokia to the public internet at all unless you have a very good reason.
And instead of using the WAR-agent I always recommend to use the JAR-agent:
* No accidental override of the security setup by an update of the jar/war
* Direct support for SSL out of the box
* Server certificates is configurable
* Verification of client certificates can be enabled
* Check that a presented client certificate is indeed a client certificate
And of course, you should restrict access to JMX with a policy file which restricts access based on IP address, the operation to be performed, and, most important, which JMX MBeans are accessible. Check out https://jolokia.org/reference/html/security.html for the details.
FYI, Jolokia 1.6.0 has just been released where the default "jolokia.war" agent is protected by a role 'jolokia' by default. In addition, a "jolokia-unsecured.war" is distributed with enforcing authentication.
So when you do a vanilla update of jolokia.war with Jolokia > 1.6.0 you have to enable your security configuration (e.g. adding role 'jolokia' to tomcat-users.xml) or switch to 'jolokia-unsecured.war' to make Jolokia work again.
This should resolve the issue to forget updating jolokia.war after an update. Nevertheless, I highly recommend to not expose the agent to the public and carefully revisit your security setup. There are even finer granular possibilities to restrict the access on MBean level by providing a policy file.
An alternative still is to use the JAR-agent instead of the WAR-agent which provides complete external security configuration with no danger to accidentally override this config by a mere update of the Jar file. Plus the JAR-agent is much more capable and allows e.g. SSL communication with client certificate verification for authentication.
Where you're actually expected to know how to set up the product you're working with and even worse: you also need to know how this product works. Because if you go in without any relevant knowledge then you can actually make horrid mistakes which could compromise security.
But how is this Jolokia's or Java's fault? I mean, anyone who knows their basics about Java management will know about MBeans. So if you're then working with something relying on MBeans, yeah... is it really that hard to add one and one up?
In my opinion this is telling us more about the shallow environment which is generally uphold within IT rather than this software product. Because like I said... how dare they expect that people actually learn their trades..
Reminds me of that "skilled" admin team who apparently couldn't understand the difference between a public and private AWS bucket and as such dumped a majority of their private keys onto the Net. For all to see and download. And of course later on blaming AWS because...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
