rsyslog

remote syslog PRI vulnerability
===============================

CVE: CVE-2014-3683

Status of this report
———————
FINAL
Updated 2014-10-06: effect on sysklogd milder than in initial assesment

Reporter
——-
mancha , intial detection and analysis
Rainer Gerhards , rsyslog project lead

Affected
——–
– rsyslog, most probably all versions (checked v3-stable and above)
– sysklogd (checked most recent versions)

Short Description
—————–
While preparing a fix for CVE-2014-3634 for sysklogd, mancha discovered and
privately reported that the initial rsyslog fix set was incomplete. It did
not cover cases where PRI values > MAX_INT caused integer overflows
resulting in negative values.

Root Cause
———-
A while parsing the syslog message’s PRI value, an integer overlow can
happen (for PRI > MAX_INT), which may cause negative PRI values. The
solutions provided in CVE-2014-3634 do not handle that case.

Effect in Practice
——————

General
~~~~~~~
Almost all distributions do ship rsyslog without remote reception by
default and almost all distros also put firewall rules into place that
prevent reception of syslog messages from remote hosts (even if rsyslog
would be listening). With these defaults, it is impossible to trigger
the vulnerability in v7 and v8. Older versions may still be vulnerable
if a malicious user writes to the local log socket.

Even when configured to receive remote message (on a central server),
it is good practice to protect such syslog servers to accept only
messages from trusted peers, e.g. within the relay chain. If setup in
such a way, a trusted peer must be compromised to send malfromed
messages. This further limits the magnitude of the vulnerability.

If, however, any system is permitted to send data unconditionally to
the syslogd, a remote attack is possible.

sysklogd
~~~~~~~~

This causes no extra problems as CVE-2014-3634 because negative
PRI values are masked off, so the overflow region is still at a
maximum of 104 bytes. For more detailsm see CVE-2014-3634.

rsyslogd
~~~~~~~~
Rsyslogd experiences the same problem as sysklogd.

As in CVE-2014-3634, rsyslog v7 and v8 have an elevated risk due to some
tables lookups used during writing. For details see CVE2014-3634.
Contrary to CVE-2014-3634, rsyslog v5 is also likely to segfault, if
and only if the patch for CVE-2014-3634 is applied.

Note that a segfault of rsyslog can cause message loss. There are multiple
scenarios for this, but likely ones are:

– reception via UDP, where all messages arriving during downtime are lost
– corruption of disk queue structures, which can lead to loss of all disk
queue contents (manual recovery is possible).

This list does not try to be complete. Note that disk queue corruption is likely
to occur in default settings, because the important queue information file (.qi)
is only written on successful shutdown. Without a valid .qi file, queue message
files cannot be processed.

How to Exploit
————–
A syslog message with a PRI > MAX_INT needs to be sent and the resulting
overflow must lead to a negative value. It is usually sufficient
to send just the PRI as in this example

“<3500000000>”

Severity
——–
Given the fact that multiple changes must be made to default system configurations
and potential problems we classify the severity of this vulnerability as

MEDIUM

Note that the probability of a successful attack is on LOW. However, the risk of
message loss is HIGH in those rare instances where an attack is successful. As
mentioned above, it cannot totally be outruled that remote code injection is
possible using this vulnerability.

Patches
——-

sysklogd
~~~~~~~~
A patch for version 1.5 is available at:
http://sf.net/projects/mancha/files/sec/sysklogd-1.5_CVE-2014-3634.diff

rsyslog
~~~~~~~
Patches are available for versions known to be in wide-spread use.

Version 8.4.2 is not vulnerable. Version 7.6.7, while no longer being project
supported, received a patch and is also not vulnerable.

Versions 8.4.1 and 7.6.6 do NOT handle integer overflows and resulting negative
PRI values correctly. So upgrading to them is NOT a sufficient solution. All
older v7 and v8 versions are vulnerable.

The rsyslog project also provides patches for older versions 5 and 3. This is
purely a convenience to those that still run these very outdated versions.
Note that these patches address the segfault issue. They do NOT offer all features
of the v7/8 series, as this would require considerate code changes. Most
importantly, the “invld” facility is not available in the v3 patch. Also,
the dead-version patches do not try to assing a specific severity to messages
with invalid PRI values nor do they prevent parsing those messages. In general,
it is suggested to upgrade to the currently supported version 8.4.2.

All patches and downloads can be found on http://www.rsyslog.com

Special thanks to mancha for his suggestions on how to fix the problem. The
core idea went into the rsyslog patches.