Bugtraq mailing list archives
syslog
From: hobbit () avian org (*Hobbit*)
Date: Tue, 29 Aug 1995 22:00:32 -0400
I screwed around some with this in the 44BSD environment today, and so far noted the following things: syslog(3) has a buffer size of 2048 that it builds the message into, but syslogd(8) has a maximum buffer size [MAXLINE] of 1024. Great, huh? What were they thinking... In the "may be obvious to some" department, but still worth pointing out to would-be implementors of a better syslog(3): snprintf and vsnprintf apparently return the length of what they WOULD have copied, REGARDLESS of a given limiting length. This is hinted at in the BSD manpage, although it also misleadingly says "These functions return the number of characters printed" for the entire class of 'em. But for *nprintf, the data actually moved is properly limited per the "cnt" argument, but a larger value can be returned. So you CANNOT rely on that return value to simply bump your buffer pointer. If there's any chance of it wandering past your buffer as a result, you have to check it after every call to *nprintf. Something like ret = snprintf (buf, x, "got %s", user_supplied_data); if (ret > x) ret = x; The excessively complex [by its own admission!] innards of BSD vfprintf seem to implement the limiting by fiddling around with stdio buffers instead of actually counting bytes, so the final count is as though the whole string were treated. This is from a vfprintf.c whose sccsid claims to be "8.1 (Berkeley) 6/4/93", so maybe newer ones work differently. This is the same one, of course, that seems to coredump if you feed it too many arguments. Needless to say, the stock BSD syslog() buffer construction relies on the return value from sprintf() to fiddle its pointers. Sigh... My mistrust of this is expressed in /src/fixkits/Hsyslog.c here, a quick-and- dirty in which not only is the buffer length-checked as it is built, but if something tries to overrun it, a "[truncated]" indication is stuffed into the end. This is also for 44bsd only at the moment; I haven't looked at Perry's patch yet and I have *no* clue where to start building a portable one for systems that don't have a basic snprintf() to begin with. [Does the Gnu stuff include one, maybe?] Sendmail 8.6.x appears to do some syslog length-checking before issuing the call in some specific places, but it's not at all clear if all the right places have this. Better to just call a paranoid syslog(). A temporary workaround might be to set the 7-bit option and hope that embedded machine instructions need their high bits on?? Wu-ftpd limits command strings to 512 characters, which at first glance would appear to make it safe for systems whose syslogs internally use 1024. But there are a few calls that have more than one reference to user-supplied data, the sum of which along with the control string can, um, add up. I also ran across a similar problem with setproctitle() while testing this, so you probably want to #undef SETPROCTITLE and forget about it for your next rebuild of ftpd and other daemons that do similar fluff. And that's only two out of a gazillion daemons that syslog() with reckless abandon. Boy howdy, we live in interesting times. _H*
Current thread:
- syslog *Hobbit* (Aug 29)