propolice and syslog-ng

Robert Connolly robert at linuxfromscratch.org
Wed Sep 29 13:09:17 PDT 2004


Hmm. This seems to work as-is:

syslog(LOG_CRIT, message, func);

Giving me:

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.
>
> -Bennett



More information about the hlfs-dev mailing list