Thanks, Piotr. I don't know what happened to your replies (maybe the spam
filter dropped them), but I am happy that we recovered from that now.
Log injections are definitely security issues, but if you prefer to talk about
them in the open, I will follow suit.
For context: a log injection occurs when an application logs user-supplied data
(which is often the case). Attacker can exploit log injection to forge log
records and impede forensics or exploit potential vulnerabilities in
log-processing systems. There is a variety of string classes that attackers can
try to inject, including newlines, ANSI sequences, Unicode direction markers,
Unicode homographs, JavaScript, PHP, etc.
Ideally, applications defend against log injection attacks by encoding (aka
escaping) user-supplied data before logging. The specific encoding depends on
the desired level of protection. URL-encoding, for instance, would protect
against all of the above-mentioned attack classes, but weaker encodings may be
sometimes acceptable as well.
A natural place to implement encoding is in the pattern layout configuration.
Some encoding pattern converters are already available in log4j, but there are
still gaps that I would like to help fill. I think there are roughly three of
them:
1. The documentation should more prominently explain the issue. Today, most
users would probably think that the following layout is HTML-safe, while it's
not:
<PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level - %enc{%m}{HTML}%n"/>
2. The HTML encoder is not always sufficient. I would like to see an addition
of a stricter one, such as a URL-encoder.
3. The current encoders encode all structured data (like the complete exception
stacktrace) and not just the injection-prone parts (i.e., the exception
message). This means I cannot replace the insecure layout above with the secure
layout
<PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level - %enc{%m}{HTML}
%enc{%xEx}{HTML}%n"/>
without changing how logs are parsed (as the stack frames will not be separated
by newlines anymore).
I have created a PoC implementation of an improved encoder, but I would
obviously need help to make it productive. Is anyone here interested in that?
Questions and comments are welcome as well.
Thanks,
Vladimir
-----Original Message-----
From: Piotr P. Karwasz <piotr.karw...@gmail.com>
Sent: Thursday, 5 October 2023 22:06
To: dev@logging.apache.org; Klebanov, Vladimir <vladimir.kleba...@sap.com>
Subject: Re: [log4j] Improving log4j security
[You don't often get email from piotr.karw...@gmail.com. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
Hi Vladimir,
On Thu, 5 Oct 2023 at 21:47, Klebanov, Vladimir
<vladimir.kleba...@sap.com.invalid> wrote:
> I would like to contribute some code in order to make log4j usage more
> secure. I have now sent two emails to the log4j security team but did not
> receive a response. Is anybody here interested? How can we discuss this
> further?
Both times (10 Aug 2023, 23:19 and 29 Aug 2023, 20:49) we sent an
answer to your address at sap.com.
Anyway the general consensus was that the issue with generating HTML
using PatternLayout does not constitute a security problem and you can
discuss it on this mailing list or file an issue in Github issues.
Piotr
