<div dir="auto">Right, 8u191 fixes a timeout issue with LDAPS.<div dir="auto"><br></div><div dir="auto">Gary</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 10, 2021, 06:10 Wessel van Norel <<a href="mailto:delgurth@gmail.com">delgurth@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">According to this translated post, 121 limits one of the attack vectors. 191 is needed to mitigate more attack vectors.<div><br></div><div><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" target="_blank" rel="noreferrer">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><br></div><div>Wessel</div><div><br><div><br><blockquote type="cite"><div>On 10 Dec 2021, at 12:05, Gary Gregory <<a href="mailto:garydgregory@gmail.com" target="_blank" rel="noreferrer">garydgregory@gmail.com</a>> wrote:</div><br><div><div dir="auto">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" target="_blank" rel="noreferrer">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"><br></div><div dir="auto">Gary</div></div><br><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" target="_blank" rel="noreferrer">ceki@qos.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hello all,<br>
<br>
You might have heard of a Remote code execution (RCE) vulnerability in <br>
log4j 2.x, that allows an attacker to execute arbitrary code by <br>
controlling the contents of a single logged message. While <br>
vulnerabilities are reported now and then, this vulnerability is totally <br>
unheard of in its severity.<br>
<br>
As for logback, while logback claims to be the successor to log4j 1.x, <br>
logback is unrelated to log4j 2.x. It does not share code nor <br>
vulnerabilities with log4j 2.x. More specifically, logback does not <br>
suffer from aforementioned said RCE vulnerability in any shape or form.<br>
<br>
Unfortunately, the vulnerability exists under SLF4J API when log4j 2.x <br>
is used as the back-end implementation. Given the severity of this <br>
issue, we encourage you to consider logback as the preferred back-end <br>
for SLF4J API.<br>
<br>
Also note that logback performs significantly better than log4 2.x.<br>
<br>
Please see the benchmark results at:<br>
<br>
<a href="http://logback.qos.ch/performance.html" rel="noreferrer noreferrer noreferrer" target="_blank">http://logback.qos.ch/performance.html</a><br>
<br>
Better yet, run the benchmark yourself.<br>
<br>
<a href="https://github.com/ceki/logback-perf" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/ceki/logback-perf</a><br>
<br>
In our opinion, logging libraries need to be reliable first and foremost <br>
with new features added only with extreme care.<br>
<br>
Best regards,<br>
<br>
Further references to the RCE vulnerability:<br>
<br>
<a href="https://www.lunasec.io/docs/blog/log4j-zero-day/" rel="noreferrer noreferrer noreferrer" target="_blank">https://www.lunasec.io/docs/blog/log4j-zero-day/</a><br>
<a href="https://twitter.com/P0rZ9/status/1468949890571337731" rel="noreferrer noreferrer noreferrer" target="_blank">https://twitter.com/P0rZ9/status/1468949890571337731</a><br>
<a href="https://github.com/apache/logging-log4j2/pull/608" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/apache/logging-log4j2/pull/608</a><br>
<br>
--<br>
Ceki Gülcü<br>
<br>
Please contact <a href="mailto:sales@qos.ch" rel="noreferrer noreferrer" target="_blank">sales@qos.ch</a> for support related to SLF4J or logback <br>
projects.<br>
_______________________________________________<br>
slf4j-dev mailing list<br>
<a href="mailto:slf4j-dev@qos.ch" rel="noreferrer noreferrer" target="_blank">slf4j-dev@qos.ch</a><br>
<a href="http://mailman.qos.ch/mailman/listinfo/slf4j-dev" rel="noreferrer noreferrer noreferrer" target="_blank">http://mailman.qos.ch/mailman/listinfo/slf4j-dev</a></blockquote></div>
_______________________________________________<br>slf4j-dev mailing list<br><a href="mailto:slf4j-dev@qos.ch" target="_blank" rel="noreferrer">slf4j-dev@qos.ch</a><br><a href="http://mailman.qos.ch/mailman/listinfo/slf4j-dev" target="_blank" rel="noreferrer">http://mailman.qos.ch/mailman/listinfo/slf4j-dev</a></div></blockquote></div><br></div></div>_______________________________________________<br>
slf4j-dev mailing list<br>
<a href="mailto:slf4j-dev@qos.ch" target="_blank" rel="noreferrer">slf4j-dev@qos.ch</a><br>
<a href="http://mailman.qos.ch/mailman/listinfo/slf4j-dev" rel="noreferrer noreferrer" target="_blank">http://mailman.qos.ch/mailman/listinfo/slf4j-dev</a></blockquote></div>