I tried to search for security Log4J issues regarding ActiveMQ 5.16.2 but I could not find any information.
Does ActiveMQ Version 5.16.2 has the Log4J security problems?
If so what should be done to close this gap?
You might review the ActiveMQ users mailing list to stay up-to-date on the latest project activity. All official support and development activities are discussed and documented on the mailing lists. This is standard practice for all Apache projects.
There's also a "News" section of the ActiveMQ website that may have relevant information like this update regarding CVE-2021-44228.
Related
I wish to inquire if there is any concern from UiPath in regards to the threat posed by the Apache Log4j vulnerability (https://amp.theguardian.com/technology/2021/dec/10/software-flaw-most-critical-vulnerability-log-4-shell). I know UiPath orchestrator runs on MS IIS and wanted to know what logging framework is used.
regarding this post in the UiPath forum Robots and Orchstrator are using NLog, which is a different framework.
Also it is mentioned that UiPath Insight is using Log4j. They are currently evaluating the impact. See here
Maybe a naive question. but many projects still use Log4j 1.x
Is there no possibility to fix at least the CVE's in Log4j 1.x? It is clear that every project should switch to log4j2. But that doesn't change the fact that the smaller security leaks in Log4j 1.x are there, even if less critical.
It it possible that the community of Log4j maybe describes how to use Log4j 1.x to be more secure. e.g. not to use some of the appenders?
The development of log4j is volunteer based. There simply aren't enough volunteers to keep maintaining all legacy applications.
And even if there is some volunteer that patches log4j 1.2 (=latest), it is still a deprecated version that is not up-to-date in many other ways (has not been updated for 6 years). Everybody should really migrate to log4j2.
Read this blog post from Apache
WSO2IS 5.8 include Log4j 1.2.17
A security vulnerability, CVE-2019-17571 has been identified against Log4j 1. Log4j includes a SocketServer that accepts serialized log events and deserializes them without verifying whether the objects are allowed or not. This can provide an attack vector that can be expoited.
Someone knows if this vulnerability can be exploited in the context of WSO2IS 5.8?
Thanks in advance!
WSO2 is very frequently issuing security patches as and when the issues are discovered. Can you please write to security#wso2.com and check.
Also - as a security best practice we recommend to use security#wso2.com all the time to report security issues - this is a common practice followed by all open source projects.
UPDATE: Even though the WSO2 Identity Server 5.8.0 has this dependency, it does not use any of the functionalities provided by SocketServer. So, anyone using 5.8.0 version is NOT affected. Also, since IS 5.9.0 this dependency is upgraded to Log4j 2.
More details here: https://wso2.com/security
I have been able to configure Hyperic HQ to identify servicemix 4, however, It could only see the "ServiceMix 4.x Garbage Collector" service. I would like to be able to monitor activemq Queues, Endpoints, and Camel Applications (if possible)
Has anyone been able to do this?
I ran into the same issue at a client recently. We didn't find any support for doing this with HypericHQ, so we built our own basic web app using JSP, Ajax/jQuery and JMX to interface with AMQ/Camel. Another option is to customize the ActiveMQ and Camel web consoles...
Here are some notes on using JMX to monitor/manage both ActiveMQ and Camel...
http://benoday.blogspot.com/2010/08/managing-camel-routes-with-jmx-apis.html
http://benoday.blogspot.com/2010/08/monitoring-and-managing-activemq-with.html
Also, I know the Camel team is looking to enhance the web console in future releases (see the 3.0 roadmap)
good luck...
I'm looking for more current recommendations on the JCL. I need to choose between using the JCL or just using straight Log4j. I can see the benefits of JCL, but articles such as http://www.qos.ch/logging/thinkAgain.jsp leave me a little unsettled. However, these articles are a bit old and a search of JCL bug fixes seems to indicate some of these issues may have been resolved. I am hoping for a more recent take on the issue. Any thoughts?
Well, this is not a direct answer to you, but I strongly recommend using Simple Logging Facade for Java (SLF4J) with Logback implementation. Logback project is meant to be a successor of Log4j project, and is built by the founder of Log4j and the author of the mentioned article.
SLF4j provides a clean interface to the various logging tools, with adaptors for legacy logging tools. This helpful when you rely on packages that rely on log4j and/or JDK logger.
A previous question discussed some of the reasons to use SLF4J project.
Check out Simple Logging Facade for Java (SLF4J). The article you referenced talks about the "classloader problem" and SLF4J is supposed to answer that.
Unless you need to support something older than java 1.4, consider just using java.util.logging. Standard is better than better, and this way you won't have any classloader problems at all.