Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 524058 (CVE-2014-3634) - <app-admin/rsyslog-8.4.1, <app-admin/sysklogd-1.5.1: Remote syslog PRI vulnerability (CVE-2014-3634)
Summary: <app-admin/rsyslog-8.4.1, <app-admin/sysklogd-1.5.1: Remote syslog PRI vulner...
Alias: CVE-2014-3634
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
Whiteboard: B3 [glsa]
: 524508 (view as bug list)
Depends on: CVE-2014-3683
  Show dependency tree
Reported: 2014-09-29 20:12 UTC by Thomas Deutschmann (RETIRED)
Modified: 2014-12-24 20:40 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

app-admin/sysklogd-1.5-r4 ebuild (sysklogd-1.5-r4.diff,5.50 KB, patch)
2014-10-03 23:00 UTC, Thomas Deutschmann (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Deutschmann (RETIRED) gentoo-dev 2014-09-29 20:12:28 UTC
remote syslog PRI vulnerability

CVE: CVE-2014-3634

Status of this report

Embargo Date
Please keep this information private until after

   2014-09-30, 12:00 CEDT

Rainer Gerhards <>, rsyslog project lead

- rsyslog, most probably all versions (checked 5.8.6+)
- sysklogd (checked most recent versions)
- potentially others (see root cause)

Root Cause
Note: rsyslogd was forked from sysklogd, and the root cause applies to
both. For simplicity, here I use sysklogd as this is the base code.

The system header file /usr/include/*/syslog.h contains the following definitions

   #define	LOG_NFACILITIES	24	/* current number of facilities */
   #define	LOG_FACMASK	0x03f8	/* mask to extract facility part */
				/* facility of pri */
   #define	LOG_FAC(p)	(((p) & LOG_FACMASK) >> 3)

[This is from Ubuntu 12.04LTS, but can be found similarly in most, if
not all, distributions].

The define LOG_NFACILITIES is used by sysklogd to size arrays for facility
processing. In sysklogd, an array for selector matching is using this. Rsyslog
has additional array. The macro LOG_FAC() is used to extract the facility from
a syslog PRI [RFC3164, RFC 5424]. Its result is used to address the arrays.
Unfortunately, the LOG_FACMASK permits PRI values up to 0x3f8 (1016 dec). This
translates to 128 facilities. Consequently, for PRI values above 191 the
LOG_NFACILITIES arrays are overrun.

Other applications may have similar problems, as LOG_NFACILITES "sounds" like
the max value that LOG_FAC() can return. It would probably make sense to
check why there is a difference between LOG_NFACILITES and LOG_FACMASK, and
if this really needs to stay. A proper fix would probably be to make LOG_FAC
return a valid (maybe special) facility if an invalid one is provided. This
is the route taken in rsyslog patches.

Effect in Practice

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 malformed
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 is mildly affected. Having a quick look at the current git master
branch, the wrong action may be applied to messages with invalid facility.

A segfault seems unlikely, as the maximum misaddressing is 104 bytes of the
f_pmask table, which is always within properly allocated memory (albeit to
wrong data items). This can lead to triggering invalid selector lines and
thus wrongly writing to files or wrongly forwarding to other hosts.

Rsyslogd experiences the same problem as sysklogd.

However, more severe effects can occur, BUT NOT WITH THE DEFAULT CONFIGURATION.
The most likely and thus important attack is a remote DoS. Some of the
additional tables are writable and can cause considerable misaddressing.
This is especially true for versions 7 and 8. In those versions, remote code
injection may also be possible by a carefully crafted package. It sounds hard
to do, but it cannot be totally outruled [we did not check this in depth].

A segfault (and thus Dos) has the following preconditions:
- the rsyslog property "pri-text" must be used, either in
  * templates
  * conditional statements (RainerScript and property-based filters)
- the property must actually be accessed
  With traditional selector lines, this depends on the facility causing
  a misaddressing that leads to reading a 1 from the misaccessed location.

When the preconditions are met, misaddressing happens. The code uses a string
table and a table of string lengths. Depending on memory layout at time of
misaddressing and depending on the actual invalid PRI value, the lookup to
the string table can lead to a much to long length, which is the used in
buffer copy calculations. High PRI values close to the max of 1016 potentially
cause most problems, but we have also seen segfaults with very low invalid
PRI values.

Note that, as usual in such situations, a segfault may not happen immediately.
Instead some data structures may be damaged (e.g. from the memory allocator)
which will later on result in a segfault.

In v5 and below, a segfault is very unlikely, as snprintf() is used to generate
the pri-text property. As such, no write overrun can happen (but still garbage
be contained inside the property). A segfault could theoretically happen if the
name lookup table indices cause out-of-process misaddressing. We could not manage
to produce a segfault with v5.

Versions 7.6.3 and 7.6.4 already have partial fixes for the issue and will not
be vulnerable to a segfault (but the mild other issues described).

All other versions 7 and 8 are vulnerable. Version 6 was not checked as it seems
no longer be used in practice (it was an interim version). No patch for
version 6 will be provided.

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 an invalid PRI value needs to be sent. It is sufficient
to send just the PRI as in this example


Any message starting with "<PRI>" where PRI is an integer greater than 191
can trigger the problem. The maximum offset that can be generated is with
PRI equal to 1016, as this is the modulus used due to LOG_FACMASK.

Note that messages with
- PRI > 191  and
- PRI modulus 1016 <= 191
will not lead to misaddressing but go into the wrong bin.

Messages with
- PRI > 191
- PRI modulus 1016 > 191
will go into the wrong bin and lead to misaddressing.

Given the triggering scenarios, the fact that multiple changes must be made to
default system configurations and potential problems we classify the severity
of this vulnerability as


Note that the probability of a successful attack is 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.

This vulnerability is at least not publicly know. Based on (no) bug reports, it
seems unlikely that it is being exploited, but that's obviously hard to know for

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

All patches and downloads can be found on (after 2014-09-30 12:00 CEDT).
Comment 1 Thomas Deutschmann (RETIRED) gentoo-dev 2014-09-29 20:27:21 UTC
@ Security:

I already prepared ebuilds for v8.4.1. Lars (polynomial-c) will commit the ebuild to portage when the advisory will be published (2014-09-30 12:00 CEDT).

For people who may ask why we will replace v7 with a new major version:
The versions in portage (v7.2) are heavily outdated.
Version 7.6.x is EOL and has some quality issues. As proxy-maintainer I DO NOT RECOMMEND to patch v7.6.
Version 8.4.x is the current stable version and best version to go.

There wouldn't be such a jump if bug 520328 would have been already addressed. But UltraBug had no time within the last 30 days...
Comment 2 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-09-30 13:14:00 UTC
+*rsyslog-8.4.1 (30 Sep 2014)
+  30 Sep 2014; Lars Wendler <> -rsyslog-7.2.7.ebuild,
+  -rsyslog-7.4.10.ebuild, -rsyslog-7.6.3-r1.ebuild, +rsyslog-8.4.1.ebuild,
+  -files/6-stable/rsyslog-6.6.0-fix-runtime.patch,
+  +files/8-stable/README.gentoo, +files/8-stable/rsyslog.confd,
+  -files/rsyslog-7.2.5-json-c-pkgconfig.patch, +files/8-stable/50-default.conf,
+  +files/8-stable/rsyslog.conf, +files/8-stable/rsyslog.initd,
+  +files/8-stable/rsyslog.logrotate, metadata.xml:
+  Security bump (bug #524058). Removed old. Remote syslog PRI vulnerability
+  (CVE-2014-3634).

How is further procedure now? Do we CC arches for stabilization while keeping the bug restricted or does someone from security team unrestrict the bug? AFAIK disclosure deadline has been expired.
Comment 3 Thomas Deutschmann (RETIRED) gentoo-dev 2014-09-30 13:17:38 UTC
Yep, the bug is now public, see

Restriction can be removed.
Comment 4 Thomas Deutschmann (RETIRED) gentoo-dev 2014-09-30 21:44:16 UTC
@ Security:

I am not sure if you will handle app-admin/sysklogd which is affected by the same bug in this bug or if somebody should fill an own bug for sysklogd.

However, this is openSUSE's patch for sysklogd:

PS: Red Hat and Novell both have raised severity.

=app-admin/rsyslog-8.4.1 should get stabilized very soon. Also, an GLSA should be issued. This bug affects systems relying on PCI-compliant logging.

Please tell us how to proceed!
Comment 5 Agostino Sarubbo gentoo-dev 2014-10-01 07:52:39 UTC
Arches, please test and mark stable:                                                                                                                                                                                                                                           
Target keywords : "amd64 hppa x86"
Comment 6 Agostino Sarubbo gentoo-dev 2014-10-01 07:59:18 UTC
(In reply to Agostino Sarubbo from comment #5)
> Arches, please test and mark stable:                                        
> =app-admin/rsyslog-8.4.1                                                    
> Target keywords : "amd64 hppa x86"

We have some deps, the full list is:

Comment 7 Jeroen Roovers (RETIRED) gentoo-dev 2014-10-01 10:59:05 UTC
Stable for HPPA.
Comment 8 Thomas Deutschmann (RETIRED) gentoo-dev 2014-10-02 14:16:06 UTC
FYI: app-admin/rsyslog-8.4.1 fix for CVE-2014-3634 was incomplete. Therefore upstream released rsyslog-8.4.2, see bug #524290 (CVE-2014-3683).
Comment 9 Thomas Deutschmann (RETIRED) gentoo-dev 2014-10-02 15:13:09 UTC
Closing this... superseded by bug #524290, app-admin/rsyslog-8.4.2 is now available in portage (thank you Lars!).
Comment 10 Chris Reffett (RETIRED) gentoo-dev Security 2014-10-02 15:36:42 UTC
Please don't close security bugs just because there's another one for the same package.
Comment 11 Thomas Deutschmann (RETIRED) gentoo-dev 2014-10-03 22:58:07 UTC
mancha released a patch for app-admin/sysklogd:

Added app-admin/sysklogd to summary and CC'ed base-system due to sysklogd's metadata.xml.
Comment 12 Thomas Deutschmann (RETIRED) gentoo-dev 2014-10-03 23:00:08 UTC
Created attachment 386014 [details, diff]
app-admin/sysklogd-1.5-r4 ebuild

Adding ebuild for sysklogd-1.5-r4 which includes the patch from mancha for CVE-2014-3634.

Please review and add it to portage.
Comment 13 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-10-04 09:22:22 UTC
+*sysklogd-1.5-r4 (04 Oct 2014)
+  04 Oct 2014; Lars Wendler <> -sysklogd-1.5.ebuild,
+  -sysklogd-1.5-r1.ebuild, +sysklogd-1.5-r4.ebuild,
+  +files/sysklogd-1.5_CVE-2014-3634.diff:
+  Security bump (bug #524058). Remote syslog PRI vulnerability (CVE-2014-3634).
+  Removed old.
Comment 14 Tobias Heinlein (RETIRED) gentoo-dev 2014-10-04 12:22:20 UTC
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
Comment 15 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-10-05 18:07:06 UTC
*** Bug 524508 has been marked as a duplicate of this bug. ***
Comment 16 mancha 2014-10-06 08:54:00 UTC
FYI, sysklogd 1.5.1 was just released which includes this fix:

Comment 17 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-10-06 16:52:30 UTC
+*sysklogd-1.5.1 (06 Oct 2014)
+  06 Oct 2014; Lars Wendler <> -sysklogd-1.5-r4.ebuild,
+  +sysklogd-1.5.1.ebuild, -files/sysklogd-1.5_CVE-2014-3634.diff:
+  Version bump which adds official upstream security release for CVE-2014-3634
+  (bug #524058).

Arches pelase proceed but with =app-admin/sysklogd-1.5.1 instead of -1.5-r4.
Comment 18 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-10-15 04:56:06 UTC
+  15 Oct 2014; Lars Wendler <> -rsyslog-7.4.4.ebuild,
+  -rsyslog-8.4.1.ebuild, -files/7-stable/50-default.conf,
+  -files/7-stable/rsyslog.conf,
+  -files/7-stable/rsyslog-7.4.3-fix-runtime.patch,
+  -files/7-stable/README.gentoo, -files/7-stable/rsyslog.confd,
+  -files/7-stable/rsyslog-7.4.3-json-c-pkgconfig.patch,
+  -files/7-stable/bugfix_52.patch, -files/7-stable/rsyslog.confd-r1,
+  -files/7-stable/rsyslog-7.x-mmjsonparse.patch,
+  -files/7-stable/bugfix_73.patch,
+  -files/7-stable/fix-omruleset-default-value.patch,
+  -files/7-stable/rsyslog.initd, -files/7-stable/rsyslog.initd-r1,
+  -files/7-stable/rsyslog.logrotate, -files/7-stable/rsyslog.logrotate-r1,
+  -files/7-stable/rsyslog-gentoo.conf, metadata.xml:
+  Removed old vulnerable versions.

Readded arches for sysklogd stabilization.
Comment 19 Tobias Klausmann (RETIRED) gentoo-dev 2014-10-15 13:25:35 UTC
Stable on alpha.
Comment 20 Jeroen Roovers (RETIRED) gentoo-dev 2014-10-15 15:57:18 UTC
Stable for HPPA.
Comment 21 Agostino Sarubbo gentoo-dev 2014-10-16 10:26:39 UTC
amd64 stable
Comment 22 Agostino Sarubbo gentoo-dev 2014-10-16 10:26:57 UTC
x86 stable
Comment 23 Agostino Sarubbo gentoo-dev 2014-10-17 13:13:49 UTC
ppc stable
Comment 24 Agostino Sarubbo gentoo-dev 2014-10-17 13:27:24 UTC
ppc64 stable
Comment 25 Agostino Sarubbo gentoo-dev 2014-10-18 14:06:47 UTC
ia64 stable
Comment 26 Agostino Sarubbo gentoo-dev 2014-10-18 14:10:56 UTC
sparc stable
Comment 27 Sergey Popov gentoo-dev 2014-10-24 07:26:10 UTC
s390 stable
Comment 28 Sean Amoss (RETIRED) gentoo-dev Security 2014-11-25 00:02:36 UTC
ARM, SH: ping
Comment 29 Markus Meier gentoo-dev 2014-11-29 19:44:11 UTC
arm stable
Comment 30 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2014-12-13 17:56:13 UTC
sh will not go stable
Comment 31 Yury German Gentoo Infrastructure gentoo-dev 2014-12-22 04:48:06 UTC
Setting to GLSA, version is no longer in tree.
Comment 32 GLSAMaker/CVETool Bot gentoo-dev 2014-12-24 20:40:30 UTC
This issue was resolved and addressed in
 GLSA 201412-35 at
by GLSA coordinator Yury German (BlueKnight).