We are using wildfly 10 and 16 in production and a zero-day exploit exists CVE-2021-44228 for log4j for some versions.
How can I be sure that none of the code and libraries use a log4j lib that has that issue?
I do not use any log4j property file nor do I add a dependency by myself.
Any help would be greatly appreciated!
The affected log4j versions are:
Versions Affected: all log4j-core versions >=2.0-beta9 and <=2.14.1
WildFly uses log4j shaded via its log4j-jboss-logmanager module. Even the latest 1.2.2.Final version depends on log4j 1.2.17.
This means WildFly <22 is definitely not affected.
There is a log4j2-jboss-logmanager as well - but only WildFly 22+ has it. And as this doc explains:
This will be an implementation of the log4j2 API only. The core log manager for log4j2 will not be supported.
Usage of any org.apache.logging.log4j:log4j-core API’s or implementations will not be supported. In other words the log4j2 log manager implementation, including configuration files, will not be supported.
You can see that the current latest 1.0.0.Final release does not depend on log4j-core at all, only log4j-api.
So WildFly versions >=22 are not affected as well.
The official tweet confirms this.
But what about WFCORE-5743 raising the log4j-core version? Look in the pom:
<!-- This is a test only dependency -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>${version.org.apache.logging.log4j}</version>
<scope>test</scope>
</dependency>
It's not bundled with WildFly, only used in WildFly's build for tests.
Fixed in WildFly Core 18.0.0, to be included in WildFly 26.0.0.Final:
https://issues.redhat.com/browse/WFCORE-5743
https://issues.redhat.com/browse/WFLY-15807
If you need to use WildFly 10 or 16 in production, you should use JBoss EAP instead:
https://access.redhat.com/articles/112673#EAP_7
Related
We need to migrate to log4j 2.17 if we are using log4j jar, mvn dependency: tree showing only log4j-over-slf4j:jar. so I assume app is safe as it will redirect call to sl4j not to log4j.
Please confirm my app is safe with this jar without any remediation.?
In the SLF4J website, in the Comments on the log4shell(CVE-2021-44228) vulnerability they state that:
If you are using log4j-over-slf4j.jar in conjunction with the SLF4J API, you are safe unless the underlying implementation is log4j 2.x.
So it basically depends on how you're implementing the logs' generation. Slf4j natively uses logback. But to be sure, you can check your pom.xml and see if log4j is mentioned there.
I wrote a program with the following package
<dependency>
<groupId>com.datastax.cassandra</groupId>
<artifactId>cassandra-driver-core</artifactId>
<version>3.6.0</version>
</dependency>
But when I change it to 4.0.0 it doesn't have some critical classes.
I search and read in Datastax that I must use the following package:
<dependency>
<groupId>com.datastax.oss</groupId>
<artifactId>java-driver-core</artifactId>
<version>4.0.0</version>
</dependency>
So, it totally have different classes, So what is the right package from Datastax to use in java for connecting and working with Cassandra? Which one is better to use and what is the main difference?
This really depends on your requirements:
if you're developing completely new application, then you need to use 4.x versions of the driver, as 3.x won't get new functionality, only critical bug fixes. Latest version right now is 4.9.0 - check documentation for exact Maven definition - it should match your second snippet. Please take into account that this driver is quite different from the 3.x versions, so copy-pasting old examples won't work, but you can follow the upgrade guide to translate them to the new version.
if you have existing code, then you may stick to the latest 3.x version (3.10 right now) because porting to 4.x versions could lead to significant rewrite of application caused by architectural changes in new version. Consult upgrade guide for details of porting. Also, you can check following repository for examples of code ported to 4.x.
I am starting to migrate an existing project from log4j1 to log4j2, i added the following maven dependencies
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-1.2-api</artifactId>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
I also deleted all logj1 jar like they say on the offical migration guide, i don't know if i have to replace all log4j.xml configuration files with log4j2.xml and change the configuration to the new syntax?
If it's the case, how i can do with third parties that use log4j and configure it with log4j.xml ?
First, there can only be a single logging configuration per application. If a third party is providing a logging configuration in a jar to be included in your app that is an issue. If it is a separate third party app then I don't understand why you are porting it from Log4j 1 to Log4j 2. That should be their problem.
Yes, your dependencies are correct. As for whether to use a log4j 1 format configuration or log4j 2 I would always recommend using the log4j 2 format if you can do the work. You can certainly try to use the log4j 1 configurations by following http://logging.apache.org/log4j/2.x/manual/compatibility.html.
I'm currently working on an application which wants to dynamically change the log level of a next java application (is running on the localhost). This external application uses log4j version 1.2.16. I want to use jmx, find all "LoggerConfigAdminMBean" and change level.
In specification (visit https://logging.apache.org/log4j/2.0/manual/jmx.html) is mentioned that it is possible with the log4j 2.
Because I do not want to do much changes in the external application, so I only changed log4j1.2.16.jar by log4j1.2bridge.jar (visit https://logging.apache.org/log4j/2.x/log4j-1.2-api/index.html). But the result of this change is empty list of LoggerConfigAdminMBean.
Is the Jmx MBeans feature completely activated by using log4j 1.2 bridge jar and is there some way to get list of LoggerConfigAdminMBean full or is it possible only by migration from log4j1 to log4j2 version?
Thank you very much for the answers.
You should use these 2 dependencies:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>2.11.1</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-1.2-api</artifactId>
<version>2.11.1</version>
</dependency>
And adapt log4j.properties, which must be placed in the project´s classpath. See: https://logging.apache.org/log4j/2.x/manual/configuration.html#Properties
Is there any reference as to what sets of versions are compatible between aws java sdk, hadoop, hadoop-aws bundle, hive, spark?
For example, I know Spark is not compatible with hive versions above Hive 2.1.1
You cannot drop in a later version of the AWS SDK from what which hadoop-aws was built with and expect the s3a connector to work. Ever. That is now written down quite clearly in the S3A troubleshooting docs
Whatever problem you have, changing the AWS SDK version will not fix things, only change the stack traces you see.
This may seem frustrating, given the rate at which the AWS team push out a new SDK, but you have to understand that (a) the API often changes incompatibly between versions (as you have seen), and (b) every release introduces/moves bugs which end up causing problems.
Here is the 3.x timeline of things which broke on updates of the AWS SDK.
Move 1.11.86 and some tests hang under load.
Fix: move to 1.11.134 leading to logs are full of AWS telling us off for deliberatly calling abort() on a read.
Fix: move to 1.11.199 leading to logs full of stack traces.
Fix: move to 1.11.271 and shaded JAR pulls in netty unshaded.
Every upgrade of the AWS SDK JAR causes a problem, somewhere. Sometimes an edit to the code and recompile, most commonly: logs filling up with false-alarm messages, dependency problems, threading quirks, etc. Things which can take time to surface.
what you see when you get a hadoop release is not just an aws-sdk JAR which it was compiled against, you get a hadoop-aws JAR which contains the workarounds and fixes for whatever problems that release has introduced and which were identified in the minimum of 4 weeks of testing before the hadoop release ships.
Which is why, no, you shouldn't be changing JARs unless you plan to do a complete end-to-end retest of the s3a client code, including load tests. You are encouraged to do that, the hadoop project always welcomes more testing of our pre-release code, with the Hadoop 3.1 binaries ready to play with. But trying to do it yourself by changing JARs? Sadly, an isolated exercise in pain.
In Hadoop documentation, it is stated that by adding hadoop-aws JAR to the build dependencies; it will pull in a compatible aws-sdk JAR.
So, I created a dummy Maven project with these dependencies to download the compatible versions
<properties>
<!-- Your exact Hadoop version here-->
<hadoop.version>3.3.1</hadoop.version>
</properties>
<dependencies>
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-client</artifactId>
<version>${hadoop.version}</version>
</dependency>
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-aws</artifactId>
<version>${hadoop.version}</version>
</dependency>
</dependencies>
Then, I checked my dependencies versions, used it in my project and it worked.