According to this translated post, 121 limits one of the attack vectors. 191 is needed to mitigate more attack vectors._______________________________________________WesselOn 10 Dec 2021, at 12:05, Gary Gregory <garydgregory@gmail.com> wrote:It also can be avoided by not using an old version of Java as Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".Gary_______________________________________________On Fri, Dec 10, 2021, 04:36 Ceki Gülcü <ceki@qos.ch> wrote:
Hello all,
You might have heard of a Remote code execution (RCE) vulnerability in
log4j 2.x, that allows an attacker to execute arbitrary code by
controlling the contents of a single logged message. While
vulnerabilities are reported now and then, this vulnerability is totally
unheard of in its severity.
As for logback, while logback claims to be the successor to log4j 1.x,
logback is unrelated to log4j 2.x. It does not share code nor
vulnerabilities with log4j 2.x. More specifically, logback does not
suffer from aforementioned said RCE vulnerability in any shape or form.
Unfortunately, the vulnerability exists under SLF4J API when log4j 2.x
is used as the back-end implementation. Given the severity of this
issue, we encourage you to consider logback as the preferred back-end
for SLF4J API.
Also note that logback performs significantly better than log4 2.x.
Please see the benchmark results at:
http://logback.qos.ch/performance.html
Better yet, run the benchmark yourself.
https://github.com/ceki/logback-perf
In our opinion, logging libraries need to be reliable first and foremost
with new features added only with extreme care.
Best regards,
Further references to the RCE vulnerability:
https://www.lunasec.io/docs/blog/log4j-zero-day/
https://twitter.com/P0rZ9/status/1468949890571337731
https://github.com/apache/logging-log4j2/pull/608
--
Ceki Gülcü
Please contact sales@qos.ch for support related to SLF4J or logback
projects.
_______________________________________________
slf4j-dev mailing list
slf4j-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-dev
slf4j-dev mailing list
slf4j-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-dev
slf4j-dev mailing list
slf4j-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-dev