There is interesting thing with event logging on Windows. The only
security aspect of it is event log record tampering and performance
degradation, but it may become sensitive is some 3rd party software is
used for automated event log analysis.
I doubt this. The event logs don't contain the actual formatted string, because
the template string is localized and only retrieved when the entry is displayed
- what is logged is just a message id and the string inserts (see documentation
for EVENTLOGRECORD). FormatMessage (which is used to build the full message to
display to the user) isn't the culprit, either, because it doesn't operate
recursively (that would have bizarre consequences, since FormatMessage also
performs automatic line wrapping and indenting) - to prove it quickly and
cheaply, make a copy of ntoskrnl.exe as %1.exe and try to run it: the error
message you get back is prepared with FormatMessage (see kernel32, message
table, entry 129), and it doesn't exhibit recursion
I think this is just a fairly minor bug/feature of the standard event log
viewer, and wouldn't affect log analyzers, unless they implement this
counterintuitive behavior (that was probably coded to support some pathological
case where a single pass of formatting wasn't enough). But I expect log
analyzers would rather work with the message source + id than the formatted
display message, anyway
Most services do not escape any user-supplied input then constructing
log event.
They are not supposed to, in fact that would damage the log. A human being
might be fooled (for example you could embed newlines and fake fields in
multi-line messages), but an automatic analysis tool will always see exactly
the parameters passed
