Escaping special characters in multiple appenders by FreeAndNil · Pull Request #315 · apache/logging-log4net

FreeAndNil · 2026-09-01T21:19:12Z

Follow-ups from the second security scan, stacked on #314. One rule, applied to
every sink that had got it wrong: content a sink cannot carry is escaped visibly,
never silently deleted, and never allowed to cost the record or the event.

LocalSyslogAppender escapes newlines, which reached syslog(3) unchanged and
let content forge a second record. NewLineHandling mirrors the remote appender,
and SyslogNewLineHandling moves out of RemoteSyslogAppender so both can use
it. Measured: glibc does no escaping of its own, contrary to the old comment.
EventLogAppender and OutputDebugStringAppender escape NUL, which ended the
stored record with no error. Measured on Windows: a 45 character message with a
NUL at 23 stored as its 23 character prefix.
RemoteSyslogAppender escapes characters outside RFC 3164 rather than deleting
them. "Schönwetter 你好" reached the collector as "Schnwetter ".
TelnetAppender and SmtpPickupDirAppender escape unpaired surrogates. Both
used a writer whose encoding throws: the first disconnected every connected
client, the second destroyed the whole buffered batch and left a truncated mail.
EventLogAppender's size limit is computed rather than guessed. The old constant
sat above the point where the service silently discards the record, so log4net
truncated events into oblivion.

Behaviour changes: syslog exception traces are now one escaped record instead of
several lines, Keep restores the old behaviour; RemoteSyslogAppender.SyslogNewLineHandling is no longer nested,
configuration binds by value name and is unaffected.

LocalSyslogAppender needs the same option, so nesting it in one of the two appenders no longer fits. Breaking for code naming RemoteSyslogAppender.SyslogNewLineHandling. Configuration binds the value by name and is unaffected.

A newline in logged content ends the record for a syslog daemon that writes the message through to a line oriented log, so content could forge a second entry that looks authentic. The code claimed syslog(3) escapes control characters itself. It does not: glibc formats the buffer and hands it over, and the escaping seen on a mainstream Linux is the daemon's. Measured with LOG_PERROR, an embedded newline comes out as two lines. NewLineHandling mirrors the option RemoteSyslogAppender has had all along, which already escaped by default. Keep restores the previous behaviour. The remote appender's habit of dropping non-ASCII is deliberately not copied.

OutputDebugStringW takes a null terminated string, so a NUL in logged content ended the record there and dropped whatever the layout rendered after it. The escape LocalSyslogAppender already had is now shared by both, since EventLogAppender is the same shape and will want it too. Its tests moved onto the shared helper with it. The appender level test only runs on Windows: Append refuses to run elsewhere.

ReportEventW takes a null terminated string, so a NUL in logged content ended the stored record there and dropped whatever the layout rendered after it. WriteEntry raises nothing, so the record simply stored short and no ErrorHandler call fired. Measured on Windows 11 build 26200: a 45 character message with a NUL at 23 stored as its 23 character prefix. Escaping happens before the size limit is applied, since it doubles each NUL, and PrepareEventText exists so that ordering can be tested without an event log.

RFC 3164 allows only visible ASCII and space in the message, and everything else fell through the loop unwritten. "Schoenwetter <CJK>" reached the collector as "Schnwetter ", and a tab vanished from between its neighbours, with no marker and no error. Such characters are now written as a \uXXXX escape, which stays inside the allowed range. Encoding still cannot make the message body non-ASCII, which the appender page now says.

Does.Not.Contain is culture sensitive, and a culture sensitive comparison treats NUL as ignorable: it reports a match in a string that contains none. Both new escape tests therefore failed on Windows against correctly escaped output. ContainsConstraint has no comparison knob at all, so these use Contains.Substring(x).Using(StringComparison.Ordinal), negated with the ! operator Constraint defines. The EventLog test asserts the whole value instead, which is ordinal and pins the length too. This is the shape f018 reports in StringMatchFilter, which is still open.