Rainer Gerhards, rsyslog project leader, discovered an issue in rsyslogd
where invalid priority values can trigger DoS and potentially RCE.
As his analysis reveals, the cause of the problem identified in rsyslog's
rsyslogd also exists in sysklogd's syslogd (from which rsyslogd was forked)
and stems from the use of a (LOG_FACMASK|LOG_PRIMASK) mask to detect invalid
priority values.
In sysklogd's syslogd, invalid priority values between 192 and 1023 (directly
or arrived at via overflow wraparound) can propagate through code causing
out-of-bounds access to the f_pmask array within the 'filed' structure by up
to 104 bytes past its end. Though most likely insufficient to reach
unallocated memory because there are around 544 bytes past f_pmask in 'filed'
(mod packing and other differences), incorrect access of fields at higher
positions of the 'filed' structure definition can cause unexpected behavior
including message mis-classification, forwarding issues, message loss,
or other.
This patch imposes a restriction on PRI message parts and requires they
be properly-delimited priority value strings that have non-negative
numerical values not exceeding 191. As before, sysklogd's syslogd permits
zero padding to not break compatibility with RFC-non-compliant loggers that
issue PRIs such as <0091>. Messages without well-formed PRI parts get
logged with priority user.notice (13). (c.f. RFC 3164)
Thanks to Rainer Gerhards for the initial report and analysis.
This patch, apparently, came from the freebsd syslogd.
The patch was subsequently lost although the old Fedora RPM can still
be found.
I took that patch, the current freebsd sources and a dash of salt to
produce a new patch which I have attached.
The patch does two things: it will arrange for syslogd to listen on an
IPv6 socket in addition to the IPv4 socket and it uses getaddrinfo()
and getnameinfo() rather than gethostby[name|addr] and getservbyname.
It would be possible to use a single socket that accepts both IPv6 and
IPv4 datagrams, but this would mean that numeric IPv4 addresses would
be prefixed with ::ffff and this could cause some confusion -- and I'm
also not sure that everything that sysklogd runs on has a dual stack
like that.
I've also introduced the -4, -6 and -A with the same meanings that the
freebsd and rsyslog variants do.
