|Summary:||<app-admin/rsyslog-8.4.2: Remote syslog PRI vulnerability (CVE-2014-3683)|
|Product:||Gentoo Security||Reporter:||Thomas Deutschmann <whissi>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Thomas Deutschmann 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 2014-10-02 14:12:07 UTC
New ebuild is ready and was sent to Lars.
Comment 2 Lars Wendler (Polynomial-C) 2014-10-02 15:04:02 UTC
+*rsyslog-8.4.2 (02 Oct 2014) + + 02 Oct 2014; Lars Wendler <firstname.lastname@example.org> +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 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
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).