[
https://issues.apache.org/jira/browse/LOG4J2-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
IngyHere updated LOG4J2-970:
----------------------------
Description:
Log4J returns errors while parsing PatternLayout in certain situations where
${map:hostName} is substituted into the pattern. This occurred on a dual-homed
Linux System with an IPv4/IPv6 dual stack. When running Java 7u60 with Log4J2
v2.1 I received errors when the hostname call reported back an IPv6
transitional address with "%3" appended to the end for whatever reason. Log4J2
then reported errors when it tried to parse the resulting pattern after
substituting the property.
Explanation: The underlying Java API that retrieves hostname values uses the
InetAddress class via InetAddress.getLocalHost().getHostName(). Returning a
single hostname on a multihomed system is inexact and uses one of several Java
API internal mechanisms that vary. If the returned value contains special
characters also used to format logging patterns, it can cause an unrecognized
format specifier error. Note that there are several bugs reported against this
API at Oracle, see http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8044306 .
Detail: See
https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-core/src/main/java/org/apache/logging/log4j/core/util/NetUtils.java
on line 45 where it collects the information.
Proposed Fix: Scrub the hostName property (probably a few other properties,
too) of any protected or special symbols that are interpreted by Log4J to
output conversions. I'm also considering a situation where a hostname can be
illegally specified in a hosts file to contain conversions -- can this happen?
NOTE: Log4J2 outputs errors about parsing the pattern but continues to parse
the remainder of the pattern and appears to continue logging successfully.
See attached log snippets.
was:
Log4J returns errors while parsing PatternLayout in certain situations where
${map:hostName} is substituted into the pattern. This occurred on a dual-homed
Linux System with an IPv4/IPv6 dual stack. When running Java 7u60 with Log4J2
v2.1 I received errors when the hostname call reported back an IPv6
transitional address with "%3" appended to the end for whatever reason. Log4J2
then reported errors when it tried to parse the resulting pattern after
substituting the property.
Explanation: The underlying Java API that retrieves hostname values uses the
InetAddress class via InetAddress.getLocalHost().getHostName(). Returning a
single hostname on a multihomed system is inexact and uses one of several Java
API internal mechanisms that vary. If the returned value contains special
characters also used to format logging patterns, it can cause an unrecognized
format specifier error. Note that there are several bugs reported against this
API at Oracle, see http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8044306 .
Detail: See
https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-core/src/main/java/org/apache/logging/log4j/core/util/NetUtils.java
on line 45 where it collects the information.
Proposed Fix: Scrub the hostName property (probably a few other properties,
too) of any protected or special symbols that are interpreted by Log4J to
output conversions. I'm also considering a situation where a hostname can be
illegally specified in a hosts file to contain conversions -- can this happen?
See attached log snippets.
> Bad Mapped Hostname Results in Errors
> -------------------------------------
>
> Key: LOG4J2-970
> URL: https://issues.apache.org/jira/browse/LOG4J2-970
> Project: Log4j 2
> Issue Type: Bug
> Components: Core, Pattern Converters
> Affects Versions: 2.1
> Reporter: IngyHere
>
> Log4J returns errors while parsing PatternLayout in certain situations where
> ${map:hostName} is substituted into the pattern. This occurred on a
> dual-homed Linux System with an IPv4/IPv6 dual stack. When running Java 7u60
> with Log4J2 v2.1 I received errors when the hostname call reported back an
> IPv6 transitional address with "%3" appended to the end for whatever reason.
> Log4J2 then reported errors when it tried to parse the resulting pattern
> after substituting the property.
> Explanation: The underlying Java API that retrieves hostname values uses the
> InetAddress class via InetAddress.getLocalHost().getHostName(). Returning a
> single hostname on a multihomed system is inexact and uses one of several
> Java API internal mechanisms that vary. If the returned value contains
> special characters also used to format logging patterns, it can cause an
> unrecognized format specifier error. Note that there are several bugs
> reported against this API at Oracle, see
> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8044306 .
> Detail: See
> https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-core/src/main/java/org/apache/logging/log4j/core/util/NetUtils.java
> on line 45 where it collects the information.
> Proposed Fix: Scrub the hostName property (probably a few other properties,
> too) of any protected or special symbols that are interpreted by Log4J to
> output conversions. I'm also considering a situation where a hostname can be
> illegally specified in a hosts file to contain conversions -- can this
> happen?
> NOTE: Log4J2 outputs errors about parsing the pattern but continues to parse
> the remainder of the pattern and appears to continue logging successfully.
> See attached log snippets.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
