Whether Archimate tool : Archi is vulnerable to the log4j [CVE-2021-44228] impact? Is it using log4j first of all.
No, the Archi Java Archimate Modeller does not use log4j and is therefore also not vulnerable to this issue.
See the answers to the question in the Forum:
https://github.com/archimatetool/archi/issues/795#issuecomment-996478526
https://forum.archimatetool.com/index.php?topic=1155.msg6168#msg6168
You can also search the code and will not find anything.
https://github.com/archimatetool/archi/search?q=log4j
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.
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
Hey I am new to Cassandra and I am friendly with Spring jdbc-template.
Can anyone please explain difference between both of them? Also can you suggest which one is good to use ?
thanks.
spring-data-cassandra uses datastax's java-driver, so the decision to be made is really whether or not you need the functionality of spring-data.
Some features from spring data that may be useful for you (documented here):
spring xml configuration for configuring your Cluster instance (especially useful if you are already using spring).
object mapping component.
The java-driver also has a mapping component as well that is worth exploring.
In my opinion if you are already using spring, it is worth looking into spring-data-cassandra. Otherwise, it would be good to start off with just the datastax java-driver.
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.