[
https://issues.apache.org/jira/browse/LOG4J2-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476007#comment-16476007
]
Gary Gregory edited comment on LOG4J2-2340 at 5/15/18 3:29 PM:
---------------------------------------------------------------
I can't say this really makes sense to me. It seems like this proposal is
narrowly focused on [~slannez]'s use case...
I am sure you can cause stack traces to occur for many other reasons.
Perhaps the solution is more of a general setting the "low level logger should
not print stack traces" and another "the status logger should not print stack
traces".
was (Author: garydgregory):
I can't say this really makes sense to me. It seems like this proposal is
narrowly focused on [~slannez]'s use case...
I am sure you can cause stack traces to occur for many other reasons.
Perhaps the solution is more of a general setting the "low level logger should
not print stack traces" and another "the status logger should not print stack
traces".
> Do not print stack trace when environment variables access is restricted
> ------------------------------------------------------------------------
>
> Key: LOG4J2-2340
> URL: https://issues.apache.org/jira/browse/LOG4J2-2340
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.11.0
> Reporter: Sebastien Lannez
> Priority: Major
> Labels: security
>
> This issue is a security issue.
> When running log4j in a restricted environment where the calling application
> is not allowed to access environment variables, then when log4j initializes a
> Logger our security manager raises a SecurityException because it tries to
> get access to all environment variables (getenv.*). The current log4j code
> properly catches the SecurityException and ignores it, which is correct as it
> allows the application to continue. The issue is that it also prints the
> exception message and the stack trace.
> Printing the exception message is a bit too much in our context (the users do
> not need to know about this issue: there is nothing he can do + the exception
> is just ignored, which means even the core log4j does not handle this case).
> But the most important issue is the stack trace printing, which can be
> exploited by an attacker (provides information about class names that he
> could impersonate).
> I suggest two code changes (most important first):
> 1/ do not print the stack trace
> 2/ do not log the exception message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
