[slf4j-dev] Remote code execution vulnerability in log4j 2.x

[Gary Gregory]

Right, 8u191 fixes a timeout issue with LDAPS.

Gary

On Fri, Dec 10, 2021, 06:10 Wessel van Norel <delgurth at gmail.com> wrote:

> According to this translated post, 121 limits one of the attack vectors.
> 191 is needed to mitigate more attack vectors.
>
>
> https://www-cnblogs-com.translate.goog/yyhuni/p/15088134.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US
>
> Wessel
>
>
> On 10 Dec 2021, at 12:05, Gary Gregory <garydgregory at 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 at 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 at qos.ch for support related to SLF4J or logback
>> projects.
>> _______________________________________________
>> slf4j-dev mailing list
>> slf4j-dev at qos.ch
>> http://mailman.qos.ch/mailman/listinfo/slf4j-dev
>
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-dev
>
>
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-dev/attachments/20211210/b212d46e/attachment-0001.html>