logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kommersz <komme...@freemail.hu>
Subject Re: Re: Log Forgery and log4j
Date Fri, 09 Aug 2013 20:29:11 GMT

  Hi Gary,

  Even this could work theoretically, but it does in reality not: in PatterLayout.format the
Converter (by default the LineSeparatorPatternConverter) is called _before_ the replace is
called (in PatterLayout.toSerializable), resulting in following: the "\r\n" added by LineSeparatorPatternConverter.format
is simply replaced, resulting in a log file containing no line feeds.

Besides this tiny bug, I still wonder: if we want proper secure file based logging, should
we address Log Forgery all times by introducing a custom replacement pattern?

I do recall Remko saying "I worry about the performance impact" and "The application knows
which points are vulnerable and it knows what form the input takes so it is best positioned
to protect itself" - all this lets me think that the main reason for concerns about updating
Log4J for protection is performance. So far I had 3 recommendations on how to fix:
Remko was suggesting to dig out linefeeds on the caller side, as then it can be selectively
applied - no doubt it would be the most performant - I just wonder if in a complex real-life
application (as for example in our case) it is really easy and straightforward to track, where
a string is coming from (was maybe mixed up with other user input, might come indirectly via
database, from a call via an untrusted source etc etc)
As with the two other proposals, it would introduce an additional layouting, either custom
(which would be maybe redundant to be implemented every time someone uses Log4J) or by configuring
PatternLayout (which is done with regex - what I would consider more questionable from a performance
perspective than a simple hand-coded replace)...

I am still somewhat insistent on that maybe a configuration option for any affected appenders
(e.g. FileAppender) would be handy - so if people want to go for so much performance, they
can turn off linefeed elimination, and risk that their logs will be tampered with.

I know I am not in a good position with my plea, as I have not been an active developer of
Log4J so far - but as I am a user of this, I am somewhat enthusiastic about making it superior,
so I would give it a last try on promoting this idea :)


> Can you do what you want with the PatternLayout's replace feature?
> Gary

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message