A security issue fixed upstream in rsyslog was announced today (September 30): http://seclists.org/oss-sec/2014/q3/863 Freeze push requested for Cauldron (fixed in version 8.4.1). Patches checked into Mageia 3 and Mageia 4 SVN. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA3TOO
Debian has issued an advisory for this on September 30: https://www.debian.org/security/2014/dsa-3040 Updated package uploaded for Cauldron. Patched packages uploaded for Mageia 3 and Mageia 4. Advisory: ======================== Updated rsyslog packages fix security vulnerability: Rainer Gerhards, the rsyslog project leader, reported a vulnerability in Rsyslog. As a consequence of this vulnerability an attacker can send malformed messages to a server, if this one accepts data from untrusted sources, and trigger a denial of service attack (CVE-2014-3634). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3634 http://seclists.org/oss-sec/2014/q3/863 https://www.debian.org/security/2014/dsa-3040 ======================== Updated packages in core/updates_testing: ======================== rsyslog-5.10.1-2.1.mga3 rsyslog-mysql-5.10.1-2.1.mga3 rsyslog-pgsql-5.10.1-2.1.mga3 rsyslog-gssapi-5.10.1-2.1.mga3 rsyslog-relp-5.10.1-2.1.mga3 rsyslog-dbi-5.10.1-2.1.mga3 rsyslog-snmp-5.10.1-2.1.mga3 rsyslog-gnutls-5.10.1-2.1.mga3 rsyslog-docs-5.10.1-2.1.mga3 rsyslog-5.10.1-3.1.mga4 rsyslog-mysql-5.10.1-3.1.mga4 rsyslog-pgsql-5.10.1-3.1.mga4 rsyslog-gssapi-5.10.1-3.1.mga4 rsyslog-relp-5.10.1-3.1.mga4 rsyslog-dbi-5.10.1-3.1.mga4 rsyslog-snmp-5.10.1-3.1.mga4 rsyslog-gnutls-5.10.1-3.1.mga4 rsyslog-docs-5.10.1-3.1.mga4 from SRPMS: rsyslog-5.10.1-2.1.mga3.src.rpm rsyslog-5.10.1-3.1.mga4.src.rpm
URL: (none) => http://lwn.net/Vulnerabilities/614401/Assignee: bugsquad => qa-bugs
Testing complete mga4 64 We ship rsyslog with remote logging disabled by default. I'm unable to trigger the segfault, which seems to require some extra configuration. Testing by enabling remote message logging and sending a log message from a 2nd install. # urpmi -ya rsyslog- (One dependency, fusiondirectory has a couple of unrelated %post errors.) Edit /etc/rsyslog.d/00_common.conf and remove the '#' comment from the two lines for UDP syslog reception. $ModLoad imudp.so $UDPServerRun 514 Then start the service # service rsyslog start # service rsyslog status Redirecting to /bin/systemctl status rsyslog.service rsyslog.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled) Active: active (running) since Thu 2014-10-02 13:23:20 BST; 1s ago Main PID: 1880 (rsyslogd) CGroup: /system.slice/rsyslog.service ââ1880 /sbin/rsyslogd -n -c 4 On a separate system use logger to send a test message with the unusual PRI mentioned in the CVE. $ logger -n <rsyslog host> --prio-prefix '<201>' Test message It can then be seen in /var/log/syslog on the rsyslog host.. # tail /var/log/syslog ... Oct 2 13:25:21 otherbox claire: <201> Test message After ----- Installing the packages together causes rapid restarts which prevent it from starting. It's unlikely many will have so many rsyslog packages installed though and not sure we can actually do anything about it anyway. # service rsyslog status Redirecting to /bin/systemctl status rsyslog.service rsyslog.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled) Active: failed (Result: start-limit) since Thu 2014-10-02 13:13:25 BST; 9min ago Main PID: 793 (code=exited, status=0/SUCCESS) ... systemd[1]: rsyslog.service start request repeated too quickly, refusing to start. It starts Ok manually afterwards. # service rsyslog start Redirecting to /bin/systemctl start rsyslog.service # service rsyslog status Redirecting to /bin/systemctl status rsyslog.service rsyslog.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled) Active: active (running) since Thu 2014-10-02 13:23:20 BST; 1s ago Main PID: 1880 (rsyslogd) CGroup: /system.slice/rsyslog.service ââ1880 /sbin/rsyslogd -n -c 4 No regressions noticed in testing or 30 minutes monitoring. # tailf /var/log/syslog
Whiteboard: MGA3TOO => MGA3TOO has_procedure mga4-64-ok
Testing complete mga4 32 Same process, all OK. Installing the updates didn't trigger the rapid restart protection on this slower computer.
Whiteboard: MGA3TOO has_procedure mga4-64-ok => MGA3TOO has_procedure mga4-32-ok mga4-64-ok
Testing complete mga3 64
Whiteboard: MGA3TOO has_procedure mga4-32-ok mga4-64-ok => MGA3TOO has_procedure mga3-64-ok mga4-32-ok mga4-64-ok
The CVE-2014-3634 fix was incomplete. http://www.rsyslog.com/remote-syslog-pri-vulnerability-cve-2014-3683/ http://www.rsyslog.com/files/download/rsyslog/CVE-2014-3683-pri-vuln.tar.gz Seems CVE-2014-3683 is this: --- rsyslog-5.10.1.old/runtime/rsyslog.h 2014-10-03 10:40:24.000000000 +0200 +++ rsyslog-5.10.1.new/runtime/rsyslog.h 2014-10-03 10:39:48.000000000 +0200 @@ -119,7 +119,7 @@ */ static inline int pri2fac(const int pri) { - int fac = pri >> 3; + unsigned fac = pri >> 3; return (fac > 23) ? LOG_FAC_INVLD : fac; } static inline int pri2sev(const int pri)
CC: (none) => oe
Bumped to rsyslog-8.4.2 in cauldron to fix CVE-2014-3683 but someone has to submit it.
Adding feedback marker then
Whiteboard: MGA3TOO has_procedure mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure feedback mga3-64-ok mga4-32-ok mga4-64-ok
Freeze push requested for Cauldron. Patched packages uploaded for Mageia 3 and Mageia 4. Advisory: ======================== Updated rsyslog packages fix security vulnerability: Rainer Gerhards, the rsyslog project leader, reported a vulnerability in Rsyslog. As a consequence of this vulnerability an attacker can send malformed messages to a server, if this one accepts data from untrusted sources, and trigger a denial of service attack (CVE-2014-3634). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3634 http://www.rsyslog.com/remote-syslog-pri-vulnerability/ http://www.rsyslog.com/remote-syslog-pri-vulnerability-cve-2014-3683/ https://www.debian.org/security/2014/dsa-3040 ======================== Updated packages in core/updates_testing: ======================== rsyslog-5.10.1-2.2.mga3 rsyslog-mysql-5.10.1-2.2.mga3 rsyslog-pgsql-5.10.1-2.2.mga3 rsyslog-gssapi-5.10.1-2.2.mga3 rsyslog-relp-5.10.1-2.2.mga3 rsyslog-dbi-5.10.1-2.2.mga3 rsyslog-snmp-5.10.1-2.2.mga3 rsyslog-gnutls-5.10.1-2.2.mga3 rsyslog-docs-5.10.1-2.2.mga3 rsyslog-5.10.1-3.2.mga4 rsyslog-mysql-5.10.1-3.2.mga4 rsyslog-pgsql-5.10.1-3.2.mga4 rsyslog-gssapi-5.10.1-3.2.mga4 rsyslog-relp-5.10.1-3.2.mga4 rsyslog-dbi-5.10.1-3.2.mga4 rsyslog-snmp-5.10.1-3.2.mga4 rsyslog-gnutls-5.10.1-3.2.mga4 rsyslog-docs-5.10.1-3.2.mga4 from SRPMS: rsyslog-5.10.1-2.2.mga3.src.rpm rsyslog-5.10.1-3.2.mga4.src.rpm
Whiteboard: MGA3TOO has_procedure feedback mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure mga3-64-ok mga4-32-ok mga4-64-ok
Whiteboard: MGA3TOO has_procedure mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure
Testing complete mga3 32 $ logger -n mga332 -p 1 --prio-prefix <3500000000> test No ill effects.
Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure mga3-32-ok
Whiteboard: MGA3TOO has_procedure mga3-32-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok
Tested Mageia 4 i586. No ill effects sending several messages similar to Claire's in Comment 2 and Comment 9.
Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok
LWN reference for CVE-2014-3683: http://lwn.net/Vulnerabilities/615338/
Testing complete mga4 64
Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok
Validating. Advisory from comment 8 uploaded. Could sysadmin please push to 3 & 4 updates Thanks
Keywords: (none) => validated_updateWhiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-okCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2014-0411.html
Status: NEW => RESOLVEDResolution: (none) => FIXED