You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Dash a <da...@gmail.com> on 2021/12/13 07:21:59 UTC

Regarding the resolution for the latest vulnerability

Hello,
Sorry to strom in for a disscusion that probably happened internally  but
correct me if I am wrong the solution offered doesn't seems to fix the
original issue which appear to be due to lack of sanitization but rather
disable it by default

This seems a bit lacking if it is the case as if some software happen to
have a use case for the feature they will be forced to apply each his own
variant solution and otherwise can be accessed by other vulnerabilities.

Hope you could verify regarding those concerns
Daniel

Re: Regarding the resolution for the latest vulnerability

Posted by Remko Popma <re...@gmail.com>.
Hi Daniel,

The plan is to disable lookups in log messages completely in the next Log4j
release.
If you can tell us your concrete use case we may be able to advise on how
to implement it safely.

Lookups in configuration will continue to work (but JNDI will require an
extra setting to be enabled).

On Mon, Dec 13, 2021 at 16:40 Dash a <da...@gmail.com> wrote:

> Hello,
> Sorry to strom in for a disscusion that probably happened internally  but
> correct me if I am wrong the solution offered doesn't seems to fix the
> original issue which appear to be due to lack of sanitization but rather
> disable it by default
>
> This seems a bit lacking if it is the case as if some software happen to
> have a use case for the feature they will be forced to apply each his own
> variant solution and otherwise can be accessed by other vulnerabilities.
>
> Hope you could verify regarding those concerns
> Daniel
>

Re: Regarding the resolution for the latest vulnerability

Posted by Ralph Goers <ra...@dslextreme.com>.
JNDI was only part of the issue but we did indeed seek to sanitize JNDI as much 
as we could in 2.15.0. However, we felt it best to disable it by default in 2.16.0 so 
that it would be more difficult to accidentally use. We will continue to look to improve 
that sanitization logic so that users who do use JNDI can do it as safely as possible or, 
if users request it, we may seek to add similar functionality using alternate APIs.

I hope that answers your question.

Ralph

> On Dec 13, 2021, at 12:21 AM, Dash a <da...@gmail.com> wrote:
> 
> Hello,
> Sorry to strom in for a disscusion that probably happened internally  but
> correct me if I am wrong the solution offered doesn't seems to fix the
> original issue which appear to be due to lack of sanitization but rather
> disable it by default
> 
> This seems a bit lacking if it is the case as if some software happen to
> have a use case for the feature they will be forced to apply each his own
> variant solution and otherwise can be accessed by other vulnerabilities.
> 
> Hope you could verify regarding those concerns
> Daniel