[ 
https://issues.apache.org/jira/browse/LOG4J2-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476007#comment-16476007
 ] 

Gary Gregory commented on LOG4J2-2340:
--------------------------------------

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)

Reply via email to