Flaws in "syslog"

[Kevin Darcy]

Tell it to Sun and all of the major Unix OS vendors. BIND just uses what comes on
the box.


- Kevin

Jonathan de Boyne Pollard wrote:

> KD> Is that a net improvement in "ease of use"? Syslog comes standard
> KD> with most if not all Unix OS'es, and most Unix admins already know
> KD> how to configure it.
>
> Ease of use may be important (although how redirecting standard error though a
> pipe to wherever one desires it to go might be considered hard to use, I don't
> know), but so too is security.  Most implementations of "syslogd" have some
> major security flaws.
>
> It is coincidental that you mentioned Solaris 8 earlier in that paragraph,
> because it is a good example of an implementation with such security flaws.
> On Solaris, "syslogd" doesn't rotate logfiles itself, as it is writing them.
> Instead, it relies on a "cron" job that runs "newsyslog", which is what
> rotates the log files.  There is nothing, therefore, stopping an attacker from
> writing large amounts of data to the system log in between invocations of
> "newsyslog" and causing unbounded growth of the log files.  (The Solaris 8
> default is for "newsyslog" to be run once per day.  An attacker can probably
> create a disc's worth of log data in a day.  (-:)  One can increase the
> frequency of the "cron" job, of course, but then one loses logging
> information.  This is because "newsyslog" rotates log files
> *unconditionally*.  It doesn't check log file sizes.  It simply performs one
> rotation every time that it is invoked.  More frequent rotations, in order to
> reduce the window of opportunity for an attacker to fill up the volume holding
> the log files, result in log data being expired more quickly.
>
> In a properly designed system, logfile rotation would be triggered when each
> log file was about to exceed the specified maximum filesize.  Of course, this
> means that it would have to be performed by the same entity that was writing
> to the logfiles, since only that entity can know when the log file is about to
> exceed its size limit and thus when the logfiles should be rotated.  A
> properly implemented "syslogd", therefore, would have log file rotation built
> in, and not rely on having something else regularly polling the log files at
> intervals to check whether they might have grown too big.
>
> "multilog" rotates log files itself in exactly this manner.