Bug 524290 (CVE-2014-3683) – <app-admin/rsyslog-8.4.2: Remote syslog PRI vulnerability (CVE-2014-3683)

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Thomas Deutschmann (RETIRED) 2014-10-02 13:35:05 UTC]

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

CVE: CVE-2014-3683

See also CVE: CVE-2014-3634 (bug #524058)

Status of this report
—————————————————————
FINAL

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
~~~~~~~~
A segfault seems possible in sysklogd if a negative facility value (due to
integer overrun in facility parsing) is used. This could be used to
carry out a remote DoS.

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 prior to v6 is also likely to segfault.

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

""

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: from mancha

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.

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.


Reproducible: Always

[Comment 1 Thomas Deutschmann (RETIRED) 2014-10-02 14:12:07 UTC]

New ebuild is ready and was sent to Lars.

[Comment 2 Lars Wendler (Polynomial-C) (RETIRED) 2014-10-02 15:04:02 UTC]

+*rsyslog-8.4.2 (02 Oct 2014)
+
+  02 Oct 2014; Lars Wendler <[e-mail]> +rsyslog-8.4.2.ebuild,
+  +files/8-stable/10-respect_CFLAGS.patch:
+  Security bump (bug 524290). Remote syslog PRI vulnerability (CVE-2014-3683).
+

[Comment 3 Thomas Deutschmann (RETIRED) 2014-10-02 15:21:08 UTC]

Arches, please test and mark stable:

=app-admin/rsyslog-8.4.2
=dev-libs/liblogging-1.0.4
=dev-libs/libmongo-client-0.1.7
=dev-libs/liblognorm-1.0.1  
=net-libs/rabbitmq-c-0.5.0
=dev-libs/librelp-1.2.7-r1

Target keywords: amd64, x86, hppa

[Comment 4 Jeroen Roovers (RETIRED) 2014-10-02 21:04:57 UTC]

Stable for HPPA.

[Comment 5 Agostino Sarubbo 2014-10-05 07:23:14 UTC]

amd64 stable

[Comment 6 Agostino Sarubbo 2014-10-05 07:25:29 UTC]

x86 stable.

Maintainer(s), please cleanup.
Security, please vote.

[Comment 7 GLSAMaker/CVETool Bot 2014-12-24 20:40:38 UTC]

This issue was resolved and addressed in
 GLSA 201412-35 at http://security.gentoo.org/glsa/glsa-201412-35.xml
by GLSA coordinator Yury German (BlueKnight).