I have upgraded my log4j-core dependency to 2.15.0 in order to prevent any potential Log4Shell attack. That being said I could not upgrade slf4j-log4j12's indirect log4j dependency from 1.2.17 since the latest stable version of slf4j-log4j12 is still dependent on log4j 1.2.17. This still leaves my webapp vulnerable to CVE-2019-17571 if I am not mistaken. So reading about possible mitigation strategies I came across this article which recommends to :
prevent the socket port enabled by the SocketServer class in Log4j
from being opened to the public network
Could anyone please explain to me how can this be achieved and whether would this workaround be sufficient?
Only servers that receive messages from other servers are vulnerable to CVE-2019-17571. Basically the only way to trigger the vulnerability is to run:
java -jar log4j.jar org.apache.log4j.net.SocketServer <port> <config.properties> <log/directory>
or doing the equivalent in code. Therefore most Log4j 1.2 users are not vulnerable.
In your case, however, you just need to replace the slf4j-log4j12 binding with its Log4j 2.x equivalent (log4j-slf4j-impl) and you can remove Log4j 1.2 altogether.
Edit: Nevertheless, if you want to be certain no one will use the library as above, you can remove the class. Considering also CVE-2021-4104 this amount to:
zip -d log4j.jar org/apache/log4j/net/SocketServer.class
zip -d log4j.jar org/apache/log4j/net/JMSAppender.class
Related
I have implemented a POC and have used slf4j for logging. The zero day vulnerability issue in log4j, did that also impact slf4j logs?
Depends on the underlying implementation of SLF4J.
log4j 1.x is safe with respect to CVE-2021-44228. Thus, if your SLF4J provider/binding is slf4j-log4j12.jar, you are safe regarding CVE-2021-44228.
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.
Check this - http://slf4j.org/log4shell.html
It depends. Slf4j is just an api, that can be using behind any of its implementions, being log4j just one. Check which one is using on the back, and if this is log4j and between versions 2.0.0 and 2.15.0 (2.15.0 is the one with the fix, versions 1.x are not affected) you should update it (if it is exposed to users directly or indirectly)
According to Apache, "only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
Also Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this."
So you should be safe, as long as you do not use log4j-core package.
[,1.7.26),[1.8.0-alpha0,1.8.0-beta2) has Vulnerabilities. Please follow the link https://snyk.io/vuln/maven:org.slf4j:slf4j-ext
I read a lot but I couldn't figure out how I could specify for example the log level for specific classes.
Only way I could figure out was in the standalone.xml but why should I configure some application specific setting very general in the server? This complicates the deployment process unnecessary.
Isn't it somehow possible to define the specific log level and the output files somewhere inside the war without touching the server?
Btw. it doesn't matter if log4j or commons-logging or slf4j or whatever is used.
Using a logging.properties file or a log4j configuration file in your deployment will work in JBoss EAP 6.x and WildFly (formerly JBoss AS). Note though that a log4j configuration would only work if you use log4j for your logging facade.
That said I agree with Marko that this should probably be done in the server configuration. I would also encourage you to use the CLI or web interface rather than editing the raw XML as well. You can get some more information on the documentation.
I am sorry for not providing a direct answer, but consider this: the application being in charge of logging levels is a bad idea most of the time as this is something an AS admin should be able to change at any time. For example, the point of the DEBUG or TRACE log levels is to be able to place a lot of such statements in the code without hurting the production server's performance. However, once a bug is detected, you want to be able to lower the logging level without rebuilding the application. This should be a purely administrative task.
On the other hand, I do recognize the need to at least have a decent starting point for the logging configuration and I don't know of any architecture which would allow the application to provide defaults which are overridable by the server configuration.
We use slf4j + logback, and happened to have some third-party libraries which use commons-logging. How do I set it up to use logback?
The answer is to not use commons-logging.jar, since SLF4J was designed to do what commons-logging does but better. As #MahdeTo refers to, you need to use jcl-over-slf4j.jar.
Check out the documentation from the slf4j website on migrating from commons-logging.
I come across this question too, and found out jcl-over-slf4j.jar indeed can solve the problem, I couldn't understand that why commons-logging couldn't use logback automatically, since commons-logging is log interface and logback is implementation, they should integrate automatically, until I found this:
The Apache Commons Logging (JCL) provides a Log interface that is
intended to be both light-weight and an independent abstraction of
other logging toolkits. It provides the middleware/tooling developer
with a simple logging abstraction, that allows the user (application
developer) to plug in a specific logging implementation.
JCL provides thin-wrapper Log implementations for other logging tools,
including Log4J, Avalon LogKit (the Avalon Framework's logging
infrastructure), JDK 1.4, and an implementation of JDK 1.4 logging
APIs (JSR-47) for pre-1.4 systems. The interface maps closely to Log4J
and LogKit.
Obviously not all the log interface can integrate nicely with log implementation which mean, if you really want to use logback, jcl-over-slf4j.jar is your only solution now because JCL only support Log4J, Logkit, JDK 1.4.
Just add jcl-over-slf4j to the dependencies of your project (check current version at https://search.maven.org/search?q=g:org.slf4j%20AND%20a:jcl-over-slf4j&core=gav)
for those all who wants to keep the final package size smaller; checkout
mvn dependency:tree result of your project and if any dependency to commons-logging exists, exclude them as well. Since the jcl-over-slf4j.jar contains both Log and LogFactory classes with exact same package structure, these commons-logging jars will be extra on your final package.
So I've been porting some of our services to use Logback over log4j and I've been using the log4j-over-slf4j jar to spoof log4j for our legacy dependencies. The only issue is log4j-over-slf4j doesn't implement many of the classes of log4j so I'm seeing a decent few class not found exceptions from dependent jars. How have people got around this? Is it enough to just put the nlog4j in your classpath instead of the log4j-over-slf4j jar? I haven't tested this last idea yet but I'm planning on it tomorrow.
Reference:
http://www.slf4j.org/legacy.html
http://www.slf4j.org/nlog4j/
The only issue is log4j-over-slf4j doesn't implement many of the classes of log4j so I'm seeing a decent few class not found exceptions from dependent jars. How have people got around this?
Well, I guess you're facing "problems" explicitly mentioned in the Bridging legacy APIs link you posted:
When does it not work?
The log4j-over-slf4j module will not
work when the application calls log4j
components that are not present in the
bridge. For example, when application
code directly references log4j
appenders, filters or the
PropertyConfigurator, then
log4j-over-slf4j would be an
insufficient replacement for log4j.
However, when log4j is configured
through a configuration file, be it
log4j.properties or log4j.xml, the
log4j-over-slf4j module should just
work fine.
If the dependent JARs are under your control, you should really try to migrate the code using the SLF4J Migrator tool.
Is it enough to just put the nlog4j in your classpath instead of the log4j-over-slf4j jar?
This might solve the ClassNotFoundException but I wonder how the whole logging is going to work. And given that NLog4J is no longer actively developed, I wonder if this is a good long term solution.
I have some jar files that will be distributed to clients that are using log4j for logging. My question is should I include a log4j.xml configuration in the jar file or have the client provide one if they want logging?
My feeling is to leave the log4j.xml configuration file out of the client jars, since the apache jar files all come with log4j logging, but sans log4j.xml.
Yes, leave it out. It's an utter nuisance when your log4j configuration file is ignored because one of the 60 third-party libraries of your app contains its own.
The good thing about log4j in your case is that your jar really shouldn't have to worry about it. The basic use case of log4j is:
Obtain a logger object for the current class
Call one of the methods on that logger, such as debug("some message");
If the jars you are shipping are to be used by a larger application, then ideally your code will only do the two steps listed above. In this way, your code will simply obtain logger objects from the already-configured log4j instance in the client's application. Your production code is then decoupled from having to know how to configure log4j.
Any logging you need to see for your development of the jars can be accomplished by configuring a log4j instance in unit test setUp() methods or something similar that won't get bundled with the production code going to the client.
I would put a default log4j configuration that you expect will be useful to your clients in the documentation. This way interested people can see what logging options you have (usually certain classes have more interesting log messages, from the user's perspective). I find it annoying when I have a third-party lib using log4j and it has no documentation, and there are log messages filling my screen and I have to try to figure out how to enable or suppress certain log messages.
If you are using log4j in your application then you include it in your project. If you are not, then why would you put it in there? What if client A wants log4j version 1.2 and client B wants log4j version 1.3.
Let them decide what they need for their projects and worry about what you need for yours.
I would add the configuration xml and load it up with instruction for the user showing different configuration and options. This will make it easier for either them or support to enable addition logging.