Bugzilla – Bug 897262
VUL-0: CVE-2014-3634: rsyslog/syslogd: remote syslog PRI vulnerability
Last modified: 2015-02-19 02:01:54 UTC
embargoed, via security@suse.de From: Rainer Gerhards <rgerhards@hq.adiscon.com> Subject: [security-team] rsyslog vuln Date: Thu, 18 Sep 2014 10:47:07 +0200 Hi there, please find attached a rsyslog security advisior (close-to-final). Please do not yet publish. Feedback is appreciated, especially on the impact severity rating. Patches will be available soon. Looking forward to your reply. Rainer remote syslog PRI vulnerability =============================== CVE: CVE-2014-3634 Status of this report --------------------- PRELIMENARY, work in progress Reporter ------- Rainer Gerhards <rgerhards@adiscon.com>, rsyslog project lead Affected -------- - rsyslog, most probably all versions (checked 5.8.6+) - sysklogd (checked most recent versions) - potentially others (see root cause) Timeline -------- 2014-09-11 issue detected during rsyslog routine maintenance 2014-09-12 confirmed for sysklogd, root cause analysis completed 2014-09-12 contacted Red Hat (Fedora), Debian, SuSe package maintainers, tried to contact sysklogd team 2014-09-15 tried to find sysklogd security contact via their mailing list 2014-09-17 notified debian security 2014-09-18 tried reaching the sysklogd team a third time 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 ------------------ 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 ~~~~~~~~ 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 misadressing 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 ~~~~~~~~ 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 misadressing. 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 misadressing that leads to reading a 1 from the misaccessed location. When the preconditions are met, misadressing happens. The code uses a string table and a table of string lengths. Depending on memory layout at time of misadressing 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. Instad 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 garbagge be contained inside the property). A segfault could theoretically happen if the name lookup table indices cause out-of-process misadressing. 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. 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 "<201>" 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 misadressing but go into the wrong bin. Messsages with - PRI > 191 - PRI modulus 1016 > 191 will go into the wrong bin and lead to misadressing. Severity -------- Given the triggering scenarios, and the fact that multiple changes must be made to default system configurations we classify the severity of this vulnerability as LOW Also, 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 sure.
issue is in msg.c::textpri() snprintf(pRes, pResLen, "%s.%s<%d>", syslog_fac_names[LOG_FAC(pri)], syslog_severity_names[LOG_PRI(pri)], pri); syslog_fac_names can be accessed past its end.
aqctually there are some writes: assert(pRes != NULL); memcpy(pRes, syslog_fac_names[LOG_FAC(pri)], len_syslog_fac_names[LOG_FAC(pri)]); pRes[len_syslog_fac_names[LOG_FAC(pri)]] = '.'; memcpy(pRes+len_syslog_fac_names[LOG_FAC(pri)]+1, syslog_severity_names[LOG_PRI(pri)], len_syslog_severity_names[LOG_PRI(pri)]+1 /* for \0! */); return pRes;
as the reporter writes, syslogd also has this confusion syslogd.c::void fprintlog(register struct filed *f, char *from, int flags,char *msg, ...) const char fac_string[LOG_NFACILITIES+1]="ABCDEFGHIJKLMNOPQRSTUVWXY"; sprintf(prilev_char, " %1d%c:", prilev, fac_string[fac]); probably a direct crash only.
syslog-ng as used in sle11 ... it uses LOG_FAC() but no LOG_NFACILITIES
Marius is valid for rsyslog
An update workflow for this issue was started. This issue was rated as important. Please submit fixed packages until 2014-09-25. When done, reassign the bug to security-team@suse.de. https://swamp.suse.de/webswamp/wf/58981
Affected packages: SLE-10-SP3-TERADATA: syslog-ng SLE-11-SP3: rsyslog, syslog-ng SLE-11-SP3-PRODUCTS: rsyslog, syslog-ng SLE-11-SP3-UPTU: rsyslog, syslog-ng
Q: As the original LOG_FAC macro stem from /usr/include/sys/syslog.h which is part of glibc-devel the question rises if this should also be fixed as shown in fixes +#undef LOG_FAC +/* we need to use a function to avoid side-effects. This MUST guard + * against invalid facility values. rgerhards, 2014-09-16 + */ +static inline int LOG_FAC(int pri) +{ + int fac = pri >> 3; + return (fac > 23) ? 23 : fac; +}
Created attachment 607160 [details] 0001-CVE-2014-3634.patch For systemd this one would protect the LOG_FAC()
The existing code in systemd/journald at least looks unaffected. the DEFINE_STRING_TABLE_LOOKUP_WITH_FALLBACK macro handles shorter array OK and is the only use of LOG_NFACILITIES.
CRD is set to September 30th.
Created attachment 607643 [details] pri-vuln.tar.gz last batch of patches and advisory
remote syslog PRI vulnerability =============================== CVE: CVE-2014-3634 Status of this report --------------------- FINAL Embargo Date ------------ Please keep this information private until after 2014-03-30, 12:00 CEDT Reporter ------- Rainer Gerhards <rgerhards@adiscon.com>, rsyslog project lead Affected -------- - 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 ------------------ 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 ~~~~~~~~ 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 misadressing 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 ~~~~~~~~ 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 misadressing. 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 misadressing that leads to reading a 1 from the misaccessed location. When the preconditions are met, misadressing happens. The code uses a string table and a table of string lengths. Depending on memory layout at time of misadressing 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. Instad 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 garbagge be contained inside the property). A segfault could theoretically happen if the name lookup table indices cause out-of-process misadressing. 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 "<201>" 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 misadressing but go into the wrong bin. Messsages with - PRI > 191 - PRI modulus 1016 > 191 will go into the wrong bin and lead to misadressing. Severity -------- 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 MEDIUM 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 sure. Patches ------- Patches are available for versions known to be in wide-spread use. Version 8.4.1 is not vulnerable. Version 7.4.6, while no longer being project supported received a patch and is also not vulnerable. All patches and downloads can be found on http://www.rsyslog.com
This is an autogenerated message for OBS integration: This bug (897262) was mentioned in https://build.opensuse.org/request/show/251836 Factory / syslogd
I agree, syslog.ng on SLE11 is not affectged, so no need for updates.
This is an autogenerated message for OBS integration: This bug (897262) was mentioned in https://build.opensuse.org/request/show/253172 12.3 / rsyslog https://build.opensuse.org/request/show/253173 13.1 / rsyslog
This is an autogenerated message for OBS integration: This bug (897262) was mentioned in https://build.opensuse.org/request/show/253177 Factory / rsyslog
This is an autogenerated message for OBS integration: This bug (897262) was mentioned in https://build.opensuse.org/request/show/253192 Factory / rsyslog https://build.opensuse.org/request/show/253193 Factory / syslogd
posted to oss-sec, is public
Patches and maintenance updates for at least rsyslog need to be re-verified: From: http://www.rsyslog.com/changelog-for-8-4-2-v8-stable/ Version 8.4.2 [v8-stable] 2014-10-02 * bugfix: the fix for CVE-2014-3634 did not handle all cases This is corrected now. see also: CVE-2014-3683 * fixed a build problem on some platforms Thanks to Olaf for the patch * behaviour change: "msg" of messages with invalid PRI set to "rawmsg" When the PRI is invalid, the rest of the header cannot be valid. So we move all of it to MSG and do not try to parse it out. Note that this is not directly related to the security issue but rather done because it makes most sense.
Do we want to reject running update to include fix for CVE-2014-3683? Or will we handle this separately?
This means 13.2 is also affected with rsyslog 8.4.1, see bug#CVE-2014-3683 (bug#899756). Should be a straight update to 8.4.2 there.
I can't follow: Factory and 13.2 are is supposed to get an update to 8.4.2. Does 13.2 need a dedicated update submit request already? Anything else is already fixed and the fixed package are submitted and the submissions are accepted -- see comment 27 and comment 32.
Ah... OK, I understand now. Going to review the pre CRD submissions.
This is an autogenerated message for OBS integration: This bug (897262) was mentioned in https://build.opensuse.org/request/show/254338 13.1 / rsyslog
This is an autogenerated message for OBS integration: This bug (897262) was mentioned in https://build.opensuse.org/request/show/254339 12.3 / rsyslog
This is an autogenerated message for OBS integration: This bug (897262) was mentioned in https://build.opensuse.org/request/show/254850 Factory / syslogd
released
SUSE-SU-2014:1294-1: An update that solves two vulnerabilities and has one errata is now available. Category: security (important) Bug References: 890228,897262,899756 CVE References: CVE-2014-3634,CVE-2014-3683 Sources used: SUSE Linux Enterprise Server 11 SP3 for VMware (src): rsyslog-5.10.1-0.11.1 SUSE Linux Enterprise Server 11 SP3 (src): rsyslog-5.10.1-0.11.1
openSUSE-SU-2014:1297-1: An update that solves two vulnerabilities and has one errata is now available. Category: security (moderate) Bug References: 890228,897262,899756 CVE References: CVE-2014-3634,CVE-2014-3683 Sources used: openSUSE 13.1 (src): rsyslog-7.4.7-2.20.1
openSUSE-SU-2014:1298-1: An update that solves two vulnerabilities and has one errata is now available. Category: security (moderate) Bug References: 890228,897262,899756 CVE References: CVE-2014-3634,CVE-2014-3683 Sources used: openSUSE 12.3 (src): rsyslog-7.2.7-2.13.1