propolice and syslog-ng
robert at linuxfromscratch.org
Wed Sep 29 13:09:17 PDT 2004
Hmm. This seems to work as-is:
syslog(LOG_CRIT, message, func);
Sep 29 15:58:09 SecondFloor fail: stack overflow in function foo
Cool beans :-) I have more playing to do but the new stack_protector.c will
look very much like obsd's, and it can shed the gpl license. I'm going to add
back the /dev/urandom fallback code cause its maybe not a bad idea. I assume
"func" is safe to use? the attacker can't really manipulate the syslog
message with it.
On September 29, 2004 11:53 am, Bennett Todd wrote:
> 2004-09-29T15:17:09 Robert Connolly:
> > Sep 29 11:07:48 SecondFloor fail: stack overflow in function %s%m
> > The "%s%m" isn't being expanded. My code is this:
> > const char message = "stack overflow in function %s";
> > ...
> > syslog(LOG_CRIT, message, "%s%m");
> > I'm going to try again without the quotes, but it looks like %s doesn't
> > expand to anything.
> Whew, that's a relief!
> The second arg of syslog is the format string, the remaining args
> are the values to interpolate into the format's %-tagged fields.
> A popular bug, very fashionable, is to log user-provided data by
> syslog(LOG_whatever, userdata);
> which lets attackers blow up the program by including cleverly bad
> %-expandos in the data that gets logged; the correct fix is
> syslog(LOG_whatever, "%s", userdata);
> since that puts one programmer-controlled expando in position for
> the format processor to see it, and the user data is no longer in a
> position to blow up the logging process.
> If syslog (or printf) %-expando processing were recursive, honoring
> %whatever in the data strings that are interpolated with %s
> recursively, the only way to safely log data that originated with an
> attacker (e.g., Message-IDs being syslogged by an MTA) would be by
> stripping anything that might be an expando out of them first, which
> means you couldn't log accurately and safely unless your stripper
> perfectly understood every aspect of the expando processor.
More information about the hlfs-dev