Hide Forgot
A flaw was reported in rsyslogd, as well as sysklogd from which it was forked, that could lead to a denial of service for rsyslogd daemons that collect remote logs from untrusted sources. In syslog.h, LOG_NFACILITIES is used to size arrays for facility processing. In sysklogd, this is used by an array for selector matching; in rsyslogd an additional array is used. The LOG_FAC() macro is used to extract the facility from a syslog PRI, which is used to address the arrays. Unfortunately, the LG_FACMASK permits values up to 0x3f8 (1016 dec), which translates to 128 facilities. As a result, any PRI values above 191 cause the LOG_NFACILITIES arrays to be overrun. If a remote attacker is able to send unconditional data to the logging server, they could cause a crash in rsyslogd, preventing the server from collecting additional logs from remote sources.
Acknowledgements: Red Hat would like to thank Rainer Gerhards of rsyslog upstream for reporting this issue.
Created attachment 938140 [details] rsyslog CVE-2014-3634 fix for v8
Created attachment 938141 [details] rsyslog CVE-2014-3634 fix for v7
Created attachment 938142 [details] rsyslog CVE-2014-3634 fix for v5.8.13
Created attachment 938143 [details] rsyslog CVE-2014-3634 fix for v3.22.4
Created attachment 938229 [details] rsyslog CVE-2014-3634 fix for v5
This is now public: http://seclists.org/oss-sec/2014/q3/863
Fixed upstream in 8.4.1 and 7.6.6: http://lists.adiscon.net/pipermail/rsyslog/2014-September/038499.html http://lists.adiscon.net/pipermail/rsyslog/2014-September/038500.html Upstream advisory with more details: External References: http://www.rsyslog.com/remote-syslog-pri-vulnerability/
This fix was incomplete. Upstream has released 8.4.2 and 7.6.7 to fully fix this issue. The 8.4.1 and 7.6.6 packages that claimed to correct it, as well as distributions that shipped with the incomplete fix, are vulnerable to CVE-2014-3683 (bug 1149081) which was assigned to the incomplete fix. Further details are available here: http://www.rsyslog.com/remote-syslog-pri-vulnerability-cve-2014-3683/ I will attach the patches that are required, in addition to those already noted, to this bug for the full and complete fix for CVE-2014-3634. As no Red Hat Enterprise Linux or Fedora packages have been provided with the incomplete fix, we are not vulnerable to this second CVE.
Created attachment 943495 [details] Additional required patch for v3.22.4
Created attachment 943496 [details] Additional required patch for v5 Also, the upstream patch tarball http://www.rsyslog.com/files/download/rsyslog/CVE-2014-3683-pri-vuln.tar.gz includes patches specific to 5.8.13 and 5.8.6 as this is a bit more of an intrusive patch.
Created rsyslog tracking bugs for this issue: Affects: fedora-all [bug 1148942]
Created attachment 943575 [details] patch to fix the flaw in sysklogd This patch is from mancha to fix the flaw in sysklogd, originally from http://sf.net/projects/mancha/files/sec/sysklogd-1.5_CVE-2014-3634.diff
Created sysklogd tracking bugs for this issue: Affects: fedora-all [bug 1148996]
This issue has different impact on sysklogd vs. rsyslog, and also on different rsyslog versions, as is hinted in the upstream advisory (see comment 11). All versions have two similar places where unexpectedly high facility number is used - f_pmask[] buffer over-read, and textpri() issues. Following comments will provide more information on each of those cases.
In sysklogd, the following place is where f_pmask[] over-read happens: http://git.infodrom.org/?p=infodrom/sysklogd;a=blob;f=syslogd.c;h=4c2014f;hb=release-1.4-1#l1596 The fac value was previously extracted from the received PRI value using LOG_FAC at: http://git.infodrom.org/?p=infodrom/sysklogd;a=blob;f=syslogd.c;h=4c2014f;hb=release-1.4-1#l1570 f_pmask is an array with the size of 25 (LOG_NFACILITIES+1), and the maximum fac value is 127 (LOG_FACMASK >> 3, where LOG_FACMASK is 0x03f8 or 1016). The f_pmask[] is member of the filed structure, followed by multiple other members of sufficient size to make over-read limited to the filed structure. http://git.infodrom.org/?p=infodrom/sysklogd;a=blob;f=syslogd.c;h=4c2014f;hb=release-1.4-1#l609 Hence this over-read can not cause sysklogd to crash. The only impact is that the decision on whether and where the message should be logged depends on the contents of the memory outside of the f_pmask[], causing the message to be logged to unexpected destinations or not logged. This impact is limited to the attacker-supplied message and does not affect other log messages processed by the syslog daemon. Additionally, attacker in control of the PRI can choose a value from the range of valid values that would cause his log message logged into any of the configured log files, or sent do any of the configured log servers. Therefore, this incorrect logging decision has no real security impact. The rsyslog inherited the f_pmask[] check from sysklogd. The following examples show the check in rsyslog 3.x and 5.x: http://git.adiscon.com/?p=rsyslog.git;a=blob;f=tools/syslogd.c;h=1028356;hb=v3-stable#l1015 http://git.adiscon.com/?p=rsyslog.git;a=blob;f=runtime/rule.c;h=828c244;hb=v5-stable#l173 The enclosing structure has different members and layout from the original sysklogd filed structure. In rsyslog, f_pmask[] over-read is not limited to the enclosing structure. However, it is still short enough to make it unlikely to cause a rsyslog crash. http://git.adiscon.com/?p=rsyslog.git;a=blob;f=tools/syslogd.h;h=e866a16;hb=v3-stable#l53 http://git.adiscon.com/?p=rsyslog.git;a=blob;f=runtime/rule.h;h=2b58587;hb=v5-stable#l30 The message mis-direction impact is the same as for sysklogd.
Another problematic place is textpri(), a function used to format specified numeric PRI value into a human-readable "facility.priority" string. Relevant code in sysklogd is: http://git.infodrom.org/?p=infodrom/sysklogd;a=blob;f=syslogd.c;h=4c2014f;hb=release-1.4-1#l1508 The function iterates of an array of known facility names and values. If the facility value is not found, NULL is used as a facility name in the snprintf() call. On Linux/glibc, printf("%s", NULL) is handled gracefully and does not cause crash. Hence this does no cause sysklogd DoS. In sysklogd, this function is called for every message, and the returned string is used in a message only printed when running in the debug mode. The function is practically identical in the rsyslog 3.x code: http://git.adiscon.com/?p=rsyslog.git;a=blob;f=runtime/msg.c;h=22303ad;hb=v3-stable#l1592 Unlike sysklogd, it is not used to format PRI value for inclusion in a debug message. It is called when any template or conditional statement defined in the rsyslog configuration uses %pri-text% property. This property is not used in the default configuration of rsyslog packages in Red Hat Enterprise Linux. The rsyslog 5.x code uses different implementation of the textpri() function: http://git.adiscon.com/?p=rsyslog.git;a=blob;f=runtime/msg.c;h=8040933;hb=v5-stable#l2244 The numeric facility value is directly used as index to the syslog_fac_names[] array. Out of bounds read causes an invalid pointer to be used, reliably triggering rsyslog daemon crash. As noted above, configurations using %pri-text% property are affected. There are further differences to the function implementation in rsyslog 7.x: http://git.adiscon.com/?p=rsyslog.git;a=blob;f=runtime/msg.c;h=6341e03;hb=v7-stable#l2452 In addition to the syslog_fac_names[] access index, facility number is also directly used to index the len_syslog_fac_names[] array. Over-read of that array may cause an unexpectedly high value to be passed as the 3rd argument to memcpy(), leading to a buffer over-write and memory corruption. This can possibly lead to code execution, as mentioned in the upstream advisory. It can also be used to reliably crash rsyslog daemon.
A summary of how this affects different syslog packages in Red Hat Enterprise Linux. - sysklogd - no DoS impact - sysklogd package in Red Hat Enterprise Linux 5 and earlier - not planned to be fixed - rsyslog 3.x - theoretical DoS in non-default configuration - rsyslog package in Red Hat Enterprise Linux 5 - may be fixed in future updates - rsyslog 5.x - DoS in non-default configuration - rsyslog5 package in Red Hat Enterprise Linux 5 - rsyslog package in Red Hat Enterprise Linux 6 - rsyslog 7.x - DoS and possibly code execution in non-default configuration - rsyslog package in Red Hat Enterprise Linux 7 - rsyslog7 package in Red Hat Enterprise Linux 6 (6.6 and later)
Created attachment 943701 [details] Local copy of pri-vuln.tar.gz Source: http://seclists.org/oss-sec/2014/q3/863
Created attachment 943702 [details] Local copy of CVE-2014-3683-pri-vuln.tar.gz Source: http://www.rsyslog.com/files/download/rsyslog/CVE-2014-3683-pri-vuln.tar.gz
(In reply to Vincent Danen from comment #14) > Additional required patch for v5 > > Also, the upstream patch tarball > http://www.rsyslog.com/files/download/rsyslog/CVE-2014-3683-pri-vuln.tar.gz > includes patches specific to 5.8.13 and 5.8.6 as this is a bit more of an > intrusive patch. To clarify, these are not additional patches, but rather updated CVE-2014-3634 patches that also address CVE-2014-3683. The actual upstream fix for CVE-2014-3683 is: http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=8a4ada4
In rsyslog, this issue can be mitigate by avoiding the use of %pri-text% property in configured templates or conditionals. It is not used in the default configuration.
IssueDescription: A flaw was found in the way rsyslog handled invalid log message priority values. In certain configurations, a local attacker, or a remote attacker able to connect to the rsyslog port, could use this flaw to crash the rsyslog daemon or, potentially in rsyslog 7.x, execute arbitrary code as the user running the rsyslog daemon.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2014:1397 https://rhn.redhat.com/errata/RHSA-2014-1397.html
rsyslog-7.4.10-5.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
rsyslog-7.4.8-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2014:1654 https://rhn.redhat.com/errata/RHSA-2014-1654.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 5 Via RHSA-2014:1671 https://rhn.redhat.com/errata/RHSA-2014-1671.html
sysklogd-1.5-18.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
sysklogd-1.5-18.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
sysklogd-1.5-18.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.