A security issue in librelp has been announced on March 23: http://openwall.com/lists/oss-security/2018/03/23/1 There doesn't appear to be a fix available yet. Mageia 5 and Mageia 6 are also affected.
Whiteboard: (none) => MGA6TOO, MGA5TOO
Assigning to all packagers collectively, since there is no registered maintainer for this package. CC'ing sander85, because he is one of the very few people who touched this package.
Assignee: bugsquad => pkg-bugsCC: (none) => mageia, marja11
Debian has issued an advisory for this on March 26: https://www.debian.org/security/2018/dsa-4151
openSUSE has issued an advisory for this on March 27: https://lists.opensuse.org/opensuse-updates/2018-03/msg00107.html
Fedora has issued an advisory for this on April 6: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/YYNMYBZOG7QOEEDAYGVRYQ2SVGNHMJUE/
Cauldron was upgraded to 1.2.15 on April 16 and is no longer vulnerable. Patched packages built for Mageia 6 and Mageia 5. Advisory: ======================== Updated librelp package fixes a security vulnerability: librelp version 1.2.14 and earlier contains a Buffer Overflow vulnerability in the checking of x509 certificates from a peer that can result in Remote code execution. This attack appear to be exploitable a remote attacker that can connect to rsyslog and trigger a stack buffer overflow by sending a specially crafted x509 certificate (CVE-2018-5145). References: http://openwall.com/lists/oss-security/2018/03/23/1 https://bugzilla.redhat.com/show_bug.cgi?id=1560084 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000140 ======================== Updated packages in core/updates_testing: ======================== lib64relp0-1.2.13-1.1.mga6 lib64relp-devel-1.2.13-1.1.mga6 from librelp-1.2.13-1.1.mga6.src.rpm lib64relp0-1.2.7-3.1.mga5 lib64relp-devel-1.2.7-3.1.mga5 from librelp-1.2.7-3.1.mga5.src.rpm
Whiteboard: MGA6TOO, MGA5TOO => MGA5TOOAssignee: pkg-bugs => qa-bugsVersion: Cauldron => 6CC: (none) => mrambo
MGA5-32 on Dell Latitude D600 Xfce No installation issues whatrequires turns up rsyslog-relp, and that one turns up just itself. Trying to find info googling, shows info , but way over me. I find info on configuring such things but not where the config lines should go into. Giving up, just remarking laptop keeps runnig OK.
CC: (none) => herman.viaene
x86_64 systems. Just starting to study rsyslog/rsyslogd as a precursor to rsyslog-relp. rsyslog has no dependency on rsyslog-relp but it looks like the relp package provides a client/server for RELP protocol messages, maybe handing them on to rsyslogd. That is a first impression - could be wrong. Continuing on Friday if all is well.
CC: (none) => tarazed25
@Len : I have had a quick look at this: be wary: Reliable Event Logging Protocol (RELP), a networking protocol for computer data logging in computer networks, extends the functionality of the syslog protocol to provide reliable delivery of event messages. librelp is an easy to use library for the RELP protocol. RELP in turn provides reliable event logging over the network. Rsyslog is an enhanced multi-threaded syslogd ... It is quite compatible to stock sysklogd and can be used as a drop-in replacement. Its advanced features make it suitable for enterprise-class, encryption protected syslog relay chains while at the same time being very easy to setup for the novice user. [!] The rsyslog-relp package contains a dynamic shared object that will add RELP support to rsyslog. o imrelp.so - This is the implementation of the RELP input module. o omrelp.so - This is the implementation of the RELP output module. Prudence is called for. My system has rsyslog, but not rsyslog-relp nor lib64relp0. Like Herman, I shall be happy just to install & update them. To invoke their use?
Coming back to this a bit late. rsyslog-relp-8.16.0-1.mga6 was already installed and so were the libraries. The online howto for setting up remote logging meant little to me but it spoke about adding relp support to rsyslog by modifying the config in /etc/rsyslog.d/. A file 04_relp.conf existed in that directory, containing: module(load="imrelp") input(type="imrelp" port="20514") module(load="omrelp") which is close to the suggested edit. The problem is I do not know how to proceed from there. It would probably mean working with another machine on the network. On the basis that discretion is the better part of valour I shall follow Lewis' suggestion and simply update the libraries. Right, that is done. Clean install and no changes in /etc/rsyslog.d $ rpm -qa | grep relp lib64relp0-1.2.13-1.1.mga6 rsyslog-relp-8.16.0-1.mga6 lib64relp-devel-1.2.13-1.1.mga6
Whiteboard: MGA5TOO => MGA5TOO MGA6-64-OK
Mageia 5, x86_64 No rsyslog on this system so I installed it out of curiosity. "switching on syslog forwarding in: /etc/systemd/journald.conf" $ ls /etc/rsyslog.d 00_common.conf Installing rsyslog-relp also pulled in lib64relp0. 04_relp.conf appeared in /etc/rsyslog.d, contents as before. Added lib64relp-devel and updated the two library packages. And that is as far as it goes.
Whiteboard: MGA5TOO MGA6-64-OK => MGA5TOO MGA6-64-OK MGA5-64-OK
By the way, I did look for a PoC but could not find anything. The exploit would have involved a buffer overflow through a vulnerability in snprintf - CVE-2018-5145 talks about a crafted x509 certificate (perhaps using that vulnerability).
@Len: brave of you to try; I was paused for clean update only, but you did more. Advisory done, but... Feedback because: @Mike: there is a discrepancy in the CVE number. The bug title & CVE ref URL are CVE-2018-1000140 ; the advisory description cites CVE-2018-5145. Whichever is right, are you able to correct either the advisory CVE number or the description; then validate this update? Or ask me to.
CC: (none) => lewyssmithKeywords: (none) => advisory, feedback
Sorry Lewis, I just blew it when I typed the advisory. I was probably multitasking and just screwed up. I don't know the process for validating so I guess you'll need to. Fixed Advisory: ======================== Updated librelp package fixes a security vulnerability: librelp version 1.2.14 and earlier contains a Buffer Overflow vulnerability in the checking of x509 certificates from a peer that can result in Remote code execution. This attack appear to be exploitable a remote attacker that can connect to rsyslog and trigger a stack buffer overflow by sending a specially crafted x509 certificate (CVE-2018-1000140). References: http://openwall.com/lists/oss-security/2018/03/23/1 https://bugzilla.redhat.com/show_bug.cgi?id=1560084 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000140 ======================== Updated packages in core/updates_testing: ======================== lib64relp0-1.2.13-1.1.mga6 lib64relp-devel-1.2.13-1.1.mga6 from librelp-1.2.13-1.1.mga6.src.rpm lib64relp0-1.2.7-3.1.mga5 lib64relp-devel-1.2.7-3.1.mga5 from librelp-1.2.7-3.1.mga5.src.rpm
Keywords: feedback => (none)
These longer CVE numbers puzzled me for a while - I thought they might be temporary, placeholders, but there has been a change of syntax to accommodate the large number of issues which can be listed during a single year; https://cve.mitre.org/cve/identifiers/syntaxchange.html
Advisory corrected as per c13. Mike - you only had to say that 1000140 and not 5145 was correct!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0251.html
Status: NEW => RESOLVEDResolution: (none) => FIXED