logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "IngyHere (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LOG4J2-970) Bad Mapped Hostname Results in Errors
Date Wed, 04 Mar 2015 05:12:04 GMT

     [ 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? 

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.




> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message