It was thus said that the Great Rainer Gerhards once stated:
> > No, I meant the semantic meaning of NUL is syslog messages. Why
> > would you
> > want to log a message with such a character? (or any of the control
> > characters really)
>
> I really don't want it, but an attacker may induce it. The need, as far as
> the discussion goes, stems back to the fact that we cannot reliably forbid
> its use. But you are right at the heart of the discussion:
>
> Should we try to forbid it (knowing that we can't 100% ensure that) or should
> we somehow handle it.
I checked my syslogd [1] and I convert any control characters to spaces
upon receipt of a message. The actual code I have:
memset(&remote,0,sizeof(remote));
remsize = sizeof(remote);
bytes = recvfrom(sock->sock,buffer,sizeof(buffer),0,(struct sockaddr
*)&remote,&remsize);
if (bytes == -1)
{
if (errno == EINTR) return;
internal_log(LOG_DEBUG,"recvfrom() = %s",strerror(errno));
return;
}
buffer[bytes] = '\0';
for (size_t i = 0 ; buffer[i] != '\0'; i++)
if (iscntrl(buffer[i]))
buffer[i] = ' ';
syslog_interp(&sock->local,&remote,buffer,&buffer[bytes]);
To me, it seemed the most logical thing to do, given that RFC-3164 disallows
control characters (if I recall it correctly). I can't control what I
receive, but I can control what I process and send.
-spc (Interesting bit o' trivia: Lua can handle NULs in strings)
[1] A custom syslogd with Lua embedded
http://www.conman.org/software/syslogintr/
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
