Our system is a microservices-based system. It has more than 120 services. We were advised to upgrade the log4j version in our microservices to 2.16.0 to mitigate the recent log4j vulnerability. Currently, our services use the 2.11.2 version. Can't we just use -Dlog4j2.formatMsgNoLookups=true to mitigate these vulnerabilities.
Look at the Apache Log4j Security Vulnerabilities page, especially the explanation under the heading "Fixed in Log4j 2.12.2 and Log4j 2.16.0".
It explains that even in 2.15.0, which had the initial fix for CVE-2021-44228, there was a situation possible in which you still had a problem, which has a new ID: CVE-2021-45046
Note that previous mitigations involving configuration such as to set the system property log4j2.formatMsgNoLookups to true do NOT mitigate this specific vulnerability.
To protect yourself against the new CVE, update to 2.16.0.
Related
I use spring-boot-starter-activemq with the lastest version of springboot (2.7.1). Our company's dependency tracker marks activemq-broker which is part of the starter as vulnerable because of CVE-2015-3208 (XML external entity - XXE). We use ActiveMQ instead of Artemis for integration with some legacy system. Is there a way to fix it or is this just a false positive ? I see that that there are updates in maven repository quite frequently (link) hence I can't believe that the vulnerability published in 2017 is not solved yet.
Thank you for your thoughts !
For our spring boot project , We are using customized spring boot library and it has been upgraded now.
But during upgrade we have kept older version of hibernate core 5.3.7.Final to support namedNativeQuery functionality.
And this version internally using older vulnerable version of log4j.
However as part of security , the overall log4j version is upgraded to latest and we can see only log4j-2.17.1 when we run the mvn dendency:list.
Is this sufficient to handle the log4j vulnarability ?
Thanks in advance.
Hibernate is not affected:
Hibernate projects are not affected by the vulnerabilities behind
CVE-2021-45046 and CVE-2021-44228: none of the Hibernate projects has
a runtime dependency on Log4j core.
Source: https://in.relation.to/2021/12/16/log4j-cve/
After Anyalysis and stack overflow help come to know that Hibernate core 5.3.7.Final is not vulnerable in spring boot project for log4j vulnerability
We understand that Jetty 11 has basically changed logging from version 10 (no internal Jetty classes, moreover Jetty 11 is commited to use SLF4 as a base logging).
The problem
We have a rudimentary knowledge of SLF4J (used it before and we've even read the Jetty 11 SLF4J sources ,too), but currently we don't see any way to "teach" Jetty 11 a new logging (aka there are no "setLogging()" methods in the Jetty 11 source code as there were before).
Global (Jetty) parameters, alas, can't be our solution just yet.
The state (aka our requirements)
We have already solved the "RequestLog" outputs of Jetty, no problems there, we need the "normal" Jetty-log outputs.
We need to control (many) modules/jars etc. via a unified logging.
Our logging is simple but requires that no output happens on the console (stdout / stderr etc). In best case the logging gets an instance of an Exception/Runtime, too.
Therefore, we need to route the Jetty output from the "Jetty server" through our internal logging. Using SLF4? If there is no other way (and we see no other way up to now), gladly.
Switching back to Jetty 10, sadly, is not an option.
Could this be solved in any way we are not aware of (yet)? Any idea would be very appreciated, thank you!
The switch from Jetty logging to Slf4j was actually done in Jetty 10.0.0.
slf4j was designed for unified logging, it can capture into a single logging location implementation all of the logging events generated from libraries that use ...
slf4j API
java.util.logging API
log4j1 API
log4j2 API
commons-logging API
logback API
org.apache.juli.logging API
and if you use slf4j version 2.x series, there's even rudimentary support for capturing java.lang.System.Logger API.
With slf4j, you have 2 categories of jar files to think about.
Bridge API JARs
These are slf4j based JARs that merely capture the above logging events and route them to slf4j. You can choose 0..n of these JARs to use.
There's dozens of options here.
Here's some common ones
jcl-overs-slf4j - captures Jakarta Commons Logging events and sends to slf4j
jul-to-slf4j - captures Java Util Logging events and sends them to slf4j
log4j-over-slf4j - captures Log4j 1.x events and sends them to slf4j
log4j2-overs-slf4j - captures Log4j 2.x events and sends them to slf4j
osgi-over-slf4j - captures osgi logging bundle events and sends them to slf4j
See http://www.slf4j.org/legacy.html
Implementation Binding JAR
These are the implementation of slf4j-api, and is the final binding of all logging events, it is the thing that decides what to do with the logging event (eg: write it to disk, ignore it, send it to a logging database, etc)
You have many choices here as well, here's some common jars to pick from (pick only 1!)
logback-classic - slf4j to Logback (Eclipse Jetty group's favorite logging implementation)
slf4j-jdk14 - slf4j to Java Util Logging
slf4j-log4j12 - slf4j to Log4j 1.2.x
log4j-slf4j-impl - slf4j to Log4j 2.x (see https://logging.apache.org/log4j/2.x/log4j-slf4j-impl/)
slfj-jcl - slf4j to Jakarta Commons Logging
jetty-slf4j-impl - Jetty 10+ implementation of the slf4j api
See: http://www.slf4j.org/manual.html#swapping
Since Jetty 10.0.x, the jetty-slf4j-impl exists, which provides an out of the box implementation that simply writes to System.err (aka STDERR) with some decent logging filtering by level in the usual jetty-logging.properties.
See https://search.maven.org/artifact/org.eclipse.jetty/jetty-slf4j-impl
Important advice
Don't use multiple binding implementations. Narrow it down to 1 binding implementation and purge all other logging implementation jars.
Don't accidentally create a loop with introducing a Bridge API Jar and a Binding Implementation JAR with the same logging technology. (eg: using binding log4j-over-slf4j and slf4j-log4j12 at the same time)
There is no "configuration" to wire up these binding or bridge jars, their mere existence in the classloader is enough to make them work. See the slf4j manual on how that works.
We have already solved the "RequestLog" outputs of Jetty, no problems there, we need the "normal" Jetty-log outputs.
Interesting, this is "solved" by actually using slf4j, as that's the only non-deprecated implementation of RequestLog.Writer in Jetty 10 and Jetty 11.
The way this works, is the Slf4jRequestLogWriter will emit events to a single named logger (the name of which you can configure in Slf4jRequestLogWriter.setLoggerName(String)) using the slf4j-api. Then it reaches the logging implementation and is routed wherever that logging configuration decides based on that logger name (file, with rolling, syslog, sent to a different system for aggregation, logstash, etc)
Did you really implement your own RequestLog.Writer instead of just using your preferred logging logging library? (libraries like logback, log4j2, log4j1, and even java.util.logging can easily create separate log files for RequestLog events).
⚠️ Note: do not use logback-access for RequestLog at this time (It does not fully support jakarta.servlets yet, and has many bugs that result in bad request log data. See open PR at https://github.com/qos-ch/logback/pull/532)
I have Spring Boot 1.4.0, HikariCP 2.4.7, slf4j-api 1.7.21 and PostgreSQL JDBC 9.4.1208.
I want to see debug logs from PostgreSQL JDBC because I have some problems with HikariCP:
HikariPool-1 - Connection is not available, request timed out after 42734ms.
How can I enable debug logging to see what's going on?
I've tried:
-Adding:
org.postgresql.Driver.setLogLevel(Driver.DEBUG);
hikariDataSource = new HikariDataSource();
hikariDataSource.setLogWriter(new PrintWriter(System.out));
-Adding to VM options:
-Dorg.slf4j.simpleLogger.defaultLogLevel=debug
However, logs are the same as they were.
Few things to consider:
Consider logging to files
1) logging to sysout may cause you to miss updates
2) it's also slow and slows your app down
Consider keeping log config in slf4j config file instead.
Consider specific Hikari config:
-Dorg.slf4j.simpleLogger.log.com.zaxxer.hikari=error
Also, by default the log level for slf4j simple logger is info. So, if you're NOT seeing anything, I don't think it's config. It may be lack of some dependency (are you just using slf4j, or something else, like log4j as well?).
Finally, are you certain that your changes are picked up at all?
Since it's hard to say on this side, let me offer another side where logging can take place: Postgres.
Try changing PG logging config:
logging_collector = on # may be 'true' for older versions as well?
log_statement = all # 'true' for older versions
log_min_error_statement = error
First turns log collector on and makes logging not lose messages.
Second says everything interests you, even simple queries with syntax errors.
Third gives your error level.
Docs for Postgres will tell you more.
I have logging working to Sentry from android just using the EventBuilder from raven-java, but I need to attach extra info which apparently EventBuilder or java.util.logging can't do.
I tried to use log4j but it doesn't pick up log4j.properties, how can I configure it with the Sentry DSN and other information? I have no preference about what logging library to use, so logback or log4j2 will do but they seem to suffer from the same problems.
I tried to configure logging programmatically but can't add the appender SentryAppender.
I also tried using android-logging-log4j library but this has the same problem.
I realize that https://github.com/joshdholtz/Sentry-Android exists which might work but it doesn't do retries in case of network issues which is quite important.
The https://github.com/joshdholtz/Sentry-Android library now supports saving of offline captures and failed captures as of version v1.1.0 - https://github.com/joshdholtz/Sentry-Android/releases/tag/v1.1.0