lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 21 Dec 2006 16:28:40 +0100
From: "Michele Cicciotti" <>
To: <>
Subject: Re: Fun with event logs (semi-offtopic)

> 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

Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists