OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 3rd quarter (Jul-Sep) 1997: Re: syslogd fun (erratum)

Re: syslogd fun (erratum)

Yuri Volobuev (volobuevT1.CHEM.UMN.EDU)
Thu, 28 Aug 1997 15:59:18 -0500 

Howdy,

I'd like to make a correction to my previous message about the syslogd
features.

First of all, like I said before, syslogd 1.3, on Linux in particular and
everywhere else it may be running, does NOT default to remote reception,
you must start it with -r option for that.  It's not really a correction,
but many people missed that part.

I wasn't exactly right about using netstat to determine if remote reception
is on.  I looked at the sources of syslogd 1.3 more carefully.  In fact,
even though it defaults to no remote reception, it creates an AF_INET socket
and binds to it unconditionally (well, if SYSLOG_INET was defined during the
compilation, and it was defined in RedHat 4.2 build).  It doesn't pay
attention to it from that point on, though, if remote reception is off, but
socket is there and it does appear in netstat output.  I don't know why it's
done this way, I guess you may consider it as a feature.  No harm, just
could be misleading.

Of course, if you don't see syslog in netstat output, at least you can be
sure it doesn't listen on the standard (514/udp) port.

So I guess one more or less simple way to find out if your syslogd is
susceptible to remote attacks, other than examining the source where
available, is to use syslog_deluxe against it and see what happens.  Of
course, there's no guarantee: if it works, you're obviously vulnerable, but
opposite may or may not be true.  Ask your vendor :)

cheers,

yuri