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
Related
I found that only neo4j > 4.2 is impacted by this vulnerability (here and here )
But in neo4j 3.5.21 pom I see a dependency to log4j (here):
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
So is this version really safe for use in production environment right now ?
Is seems that log4j version 1.2.17 is used in neo4j 3.5.21 and this version is not vulnerable to https://nvd.nist.gov/vuln/detail/CVE-2021-44228 as the vulnerability was introduced with version 2.10.0.
In any way log4j version 1.2.17 is vulnerable to https://nvd.nist.gov/vuln/detail/CVE-2019-17571 which has a score of 9.8 out of 10. It is a different attack vector maybe harder to exploit, but same as critical and should not be used in production.
You should update your neo4j version in any way.
The sky is not falling. To be clear Log4j 1.2.17 does NOT suffer from the ZDV. Are you running the rarely used network socket appender or JDBC appender servers? Is Neo4j? (I don't think so.) If you are not, then there is no reason to urgently toss software in the trash that relies on Log4j 1.x.*
One thing for sure is that Log4j2 is a breaking API change, which means you cannot just stuff a new JAR in and hope it works. (Package names and config specs changed.) If code is written well using a logging abstraction layer, like SLF4J, then it's a snap. However, if code relies on programmatic config settings, there will be pain. Upgrading to Log4j2 can be a non-trivial task.
* Note that Log4j 1.x has been out of its support window for a few years now. Also, Log4j2 was a complete rewrite of the API that is less resource intensive, less locking and quite faster (thanks to the LMAX Disruptor). There are reasons to upgrade but not as an emergency.
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 wonder if there is a compatibility matrix for the various Hadoop components of the eco-system ?
Each Hadoop upgrade has big compatibility impact, e.g:
Apache Spark 2.4 does not support Hadoop v3,
Hadoop does not support Java 9 and 10,
and so on...
I know that vendors such as Hortonworks publish components lists with each version of their distribution, but this is not meant for the public in large because this includes patched components.
Does one have to go through all the bug trackers over at Jira for each tool to find out about compatibility problems ?
One of the key things that a company like Cloudera/Hortonworks does is taking all the open source projects that make up Hadoop and making sure that they work well together. Both from a functional perspective as well as security a lot of testing and tweaking is done to ensure that everything together forms a proper release.
Now that you have some insight how much effort goes into the release of just one distribution with comparatively strong focus on recent versions, you might understand that there will not be a general overview of 'how everything works with everything' beyond these distributions.
Full disclosure: I am an employee of Cloudera, but even without this I would still recommend you to work with a distribution where possible
Read about JSR-107 and JCache recently.
Would like to know whether Hazelcast or Ehcache follow this JSR?
JSR107 (JCache) made good progress and we already notified the spec committee that Hazelcast will implement the JCache spec. Having JCache part of Java EE 8 will be significant achievement so Hazelcast is now committed to JCache.
-talip (hazelcast founder)
As far as Hazelcast goes, here is a response from Talip Ozturk:
> 1. Does hazelcast have any plans to support JSR107? If so, any release date?
It shouldn't be hard to support JSR107 but it is a 10 years old JSR
that is never been finalized. We don't want to spend time on it until
we see an official release of the spec.
Found on this page.
As far as Ehcache goes, here is a possible implementation that may work: https://github.com/jsr107/ehcache-jcache
Hazelcast 3.3.1 passed the JSR107 final TCK and was accepted by the JCP as compatible. Makes sense since the JCache spec co-author is the CEO of Hazelcast
You can download it at http://hazelcast.org/download
If you need an implementation of JCache, the only one that I'm aware of being available today is Oracle Coherence; see: http://docs.oracle.com/middleware/1213/coherence/develop-applications/jcache_part.htm
For the sake of full disclosure, I work at Oracle. The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.
Hazelcast is now fully complied with Jsr107 or Jcache. This is announced in the official Blog
On the opening day of JavaOne and Oracle Open World, Hazelcast, the leading In-Memory Data Grid provider is announcing the release of Hazelcast 3.3.1 JCache, the JCache compatible version of Hazelcast.
And acording to this
Hazelcast JCache implementation is 100% TCK (Technology Compatibility Kit) compliant and therefore passes all specification requirements.
The samples in hazel cast makes it somewhat easy to learn jcache as there is really poor JavaDocs and other resources
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.