<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">According to this translated post, 121 limits one of the attack vectors. 191 is needed to mitigate more attack vectors.<div class=""><br class=""></div><div class=""><a href="https://www-cnblogs-com.translate.goog/yyhuni/p/15088134.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US" class="">https://www-cnblogs-com.translate.goog/yyhuni/p/15088134.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US</a></div><div class=""><br class=""></div><div class="">Wessel</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 10 Dec 2021, at 12:05, Gary Gregory <<a href="mailto:garydgregory@gmail.com" class="">garydgregory@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class="">It also can be avoided by not using an old version of Java as Java 8u121 (see <a href="https://www.oracle.com/java/technologies/javase/8u121-relnotes.html" class="">https://www.oracle.com/java/technologies/javase/8u121-relnotes.html</a>) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".<div dir="auto" class=""><br class=""></div><div dir="auto" class="">Gary</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 10, 2021, 04:36 Ceki Gülcü <<a href="mailto:ceki@qos.ch" class="">ceki@qos.ch</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
Hello all,<br class="">
<br class="">
You might have heard of a Remote code execution (RCE) vulnerability in <br class="">
log4j 2.x, that allows an attacker to execute arbitrary code by <br class="">
controlling the contents of a single logged message. While <br class="">
vulnerabilities are reported now and then, this vulnerability is totally <br class="">
unheard of in its severity.<br class="">
<br class="">
As for logback, while logback claims to be the successor to log4j 1.x, <br class="">
logback is unrelated to log4j 2.x. It does not share code nor <br class="">
vulnerabilities with log4j 2.x. More specifically, logback does not <br class="">
suffer from aforementioned said RCE vulnerability in any shape or form.<br class="">
<br class="">
Unfortunately, the vulnerability exists under SLF4J API when log4j 2.x <br class="">
is used as the back-end implementation. Given the severity of this <br class="">
issue, we encourage you to consider logback as the preferred back-end <br class="">
for SLF4J API.<br class="">
<br class="">
Also note that logback performs significantly better than log4 2.x.<br class="">
<br class="">
Please see the benchmark results at:<br class="">
<br class="">
<a href="http://logback.qos.ch/performance.html" rel="noreferrer noreferrer" target="_blank" class="">http://logback.qos.ch/performance.html</a><br class="">
<br class="">
Better yet, run the benchmark yourself.<br class="">
<br class="">
<a href="https://github.com/ceki/logback-perf" rel="noreferrer noreferrer" target="_blank" class="">https://github.com/ceki/logback-perf</a><br class="">
<br class="">
In our opinion, logging libraries need to be reliable first and foremost <br class="">
with new features added only with extreme care.<br class="">
<br class="">
Best regards,<br class="">
<br class="">
Further references to the RCE vulnerability:<br class="">
<br class="">
<a href="https://www.lunasec.io/docs/blog/log4j-zero-day/" rel="noreferrer noreferrer" target="_blank" class="">https://www.lunasec.io/docs/blog/log4j-zero-day/</a><br class="">
<a href="https://twitter.com/P0rZ9/status/1468949890571337731" rel="noreferrer noreferrer" target="_blank" class="">https://twitter.com/P0rZ9/status/1468949890571337731</a><br class="">
<a href="https://github.com/apache/logging-log4j2/pull/608" rel="noreferrer noreferrer" target="_blank" class="">https://github.com/apache/logging-log4j2/pull/608</a><br class="">
<br class="">
--<br class="">
Ceki Gülcü<br class="">
<br class="">
Please contact <a href="mailto:sales@qos.ch" target="_blank" rel="noreferrer" class="">sales@qos.ch</a> for support related to SLF4J or logback <br class="">
projects.<br class="">
_______________________________________________<br class="">
slf4j-dev mailing list<br class="">
<a href="mailto:slf4j-dev@qos.ch" target="_blank" rel="noreferrer" class="">slf4j-dev@qos.ch</a><br class="">
<a href="http://mailman.qos.ch/mailman/listinfo/slf4j-dev" rel="noreferrer noreferrer" target="_blank" class="">http://mailman.qos.ch/mailman/listinfo/slf4j-dev</a></blockquote></div>
_______________________________________________<br class="">slf4j-dev mailing list<br class=""><a href="mailto:slf4j-dev@qos.ch" class="">slf4j-dev@qos.ch</a><br class="">http://mailman.qos.ch/mailman/listinfo/slf4j-dev</div></blockquote></div><br class=""></div></body></html>