SUSE has issued an advisory on June 28: https://lists.suse.com/pipermail/sle-security-updates/2021-June/009098.html We are affected because of the arpwatch-2.1a13-drop_root.diff patch. Mageia 7 and Mageia 8 are also affected.
Whiteboard: (none) => MGA8TOO, MGA7TOO
This SRPM has no particular maintainer, so having to assign this update globally.
Assignee: bugsquad => pkg-bugs
openSUSE has issued an advisory for this today (July 1): https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/Y7SKTH3533HITV3EN436RULMJP2HHQND/
Removing Mageia 7 from whiteboard due to EOL: https://blog.mageia.org/en/2021/06/08/mageia-7-will-reach-end-of-support-on-30th-of-june-the-king-is-dead-long-live-the-king/
Status comment: (none) => Patch available from openSUSEWhiteboard: MGA8TOO, MGA7TOO => MGA8TOO
Suggested advisory: ======================== The updated package fixes a security vulnerability: A UNIX Symbolic Link (Symlink) Following vulnerability in arpwatch of SUSE Linux Enterprise Server 11-SP4-LTSS, SUSE Manager Server 4.0, SUSE OpenStack Cloud Crowbar 9; openSUSE Factory, Leap 15.2 allows local attackers with control of the runtime user to run arpwatch as to escalate to root upon the next restart of arpwatch. This issue affects: SUSE Linux Enterprise Server 11-SP4-LTSS arpwatch versions prior to 2.1a15. SUSE Manager Server 4.0 arpwatch versions prior to 2.1a15. SUSE OpenStack Cloud Crowbar 9 arpwatch versions prior to 2.1a15. openSUSE Factory arpwatch version 2.1a15-169.5 and prior versions. openSUSE Leap 15.2 arpwatch version 2.1a15-lp152.5.5 and prior versions. (CVE-2021-25321) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25321 https://lists.suse.com/pipermail/sle-security-updates/2021-June/009098.html https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/Y7SKTH3533HITV3EN436RULMJP2HHQND/ ======================== Updated package in core/updates_testing: ======================== arpwatch-2.1a15-21.1.mga8 from SRPM: arpwatch-2.1a15-21.1.mga8.src.rpm
Status: NEW => ASSIGNEDStatus comment: Patch available from openSUSE => (none)Whiteboard: MGA8TOO => (none)CVE: (none) => CVE-2021-25321CC: (none) => nicolas.salgueroAssignee: pkg-bugs => qa-bugsVersion: Cauldron => 8
MGA8-64 Plasma on Lenovo B50 No installation issues. After altering /etc/sysconfig/arpwatch as per bug 6329 to reflect my LAN # systemctl start arpwatch # systemctl -l status arpwatch ● arpwatch.service - LSB: The arpwatch daemon Loaded: loaded (/etc/rc.d/init.d/arpwatch; generated) Active: active (exited) since Tue 2021-07-20 15:27:51 CEST; 2s ago Docs: man:systemd-sysv-generator(8) Process: 19576 ExecStart=/etc/rc.d/init.d/arpwatch start (code=exited, status=0/SUCCESS) CPU: 27ms jul 20 15:27:51 mach5.hviaene.thuis systemd[1]: Starting LSB: The arpwatch daemon... jul 20 15:27:51 mach5.hviaene.thuis arpwatch[19576]: Starting arpwatch: [ OK ] jul 20 15:27:51 mach5.hviaene.thuis systemd[1]: Started LSB: The arpwatch daemon. jul 20 15:27:51 mach5.hviaene.thuis arpwatch[19585]: Fatal: cannot determine directory of arp.dat No arpwatch process running. Checked: there is a file arp.dat in /vat/lib/arpwatch, so that should be OK ???? But https://www.tecmint.com/monitor-ethernet-activity-in-linux/ tells the file should reside in /var/arpwatch ????? Googling does not get me any further.
CC: (none) => herman.viaene
There are problems. First installing the update is renaming the arpwatch owned file /var/lib/arpwatch/arp.dat to /var/lib/arpwatch/arp.dat.rpmsave and creating a root owned file in it's place that arpwatch can not update. Second after fixing that issue, it doesn't seem to be detecting new arp entries. [root@x3 ~]# arp Address HWtype HWaddress Flags Mask Iface router ether 84:d8:1b:58:e7:4c C eth0 hodgins.homeip.net ether 00:1e:8c:c5:25:f2 C eth0 [root@x3 ~]# arp Address HWtype HWaddress Flags Mask Iface router ether 84:d8:1b:58:e7:4c C eth0 x8t.hodgins.homeip.net ether 70:66:55:c3:ec:83 C eth0 hodgins.homeip.net ether 00:1e:8c:c5:25:f2 C eth0 [root@x3 ~]# systemctl status arpwatch.service ● arpwatch.service - LSB: The arpwatch daemon Loaded: loaded (/etc/rc.d/init.d/arpwatch; generated) Active: active (exited) since Tue 2021-07-20 14:22:39 EDT; 3min 31s ago Docs: man:systemd-sysv-generator(8) Process: 1420 ExecStart=/etc/rc.d/init.d/arpwatch start (code=exited, status=0/SUCCESS) CPU: 23ms Jul 20 14:22:39 x3.hodgins.homeip.net systemd[1]: Starting LSB: The arpwatch daemon... Jul 20 14:22:39 x3.hodgins.homeip.net arpwatch[1420]: Starting arpwatch: [ OK ] Jul 20 14:22:39 x3.hodgins.homeip.net systemd[1]: Started LSB: The arpwatch daemon. No mail generated by the addition of x8t.hodgins.homeip.net I'll try some additional debugging to see if I've got a configuration problem or if it's just not working.
CC: (none) => davidwhodgins
After starting the service, the arpwatch daemon exits immediately rather then continuing running. Running as root, the command ... # arpwatch -f /var/lib/arpwatch/arp.dat -i eth0 -n "192.168.10.2/16" -u arpwatch works (those config settings match my current install). So the problem, besides the ownership of arp.dat is the way it's being started. I'm not sure what's wrong with the current /etc/rc.d/init.d/arpwatch file. I recommend replacing it with a systemd config file. As it is, it's a non-functional package.
Keywords: (none) => feedback
@ Dave Mine is a fresh install of arpwatch, and I see that the folder arpwatch in /var/lib is owned by user arpwatch, but all the files in it are owned by root Did a chown and chgrp on the files, but the problem remains.
Reassigning back to packager
Assignee: qa-bugs => nicolas.salguero
arpwatch-2.1a15-21.2.mga8 solves the issue described in comment 5. Suggested advisory: ======================== The updated package fixes a security vulnerability: A UNIX Symbolic Link (Symlink) Following vulnerability in arpwatch of SUSE Linux Enterprise Server 11-SP4-LTSS, SUSE Manager Server 4.0, SUSE OpenStack Cloud Crowbar 9; openSUSE Factory, Leap 15.2 allows local attackers with control of the runtime user to run arpwatch as to escalate to root upon the next restart of arpwatch. This issue affects: SUSE Linux Enterprise Server 11-SP4-LTSS arpwatch versions prior to 2.1a15. SUSE Manager Server 4.0 arpwatch versions prior to 2.1a15. SUSE OpenStack Cloud Crowbar 9 arpwatch versions prior to 2.1a15. openSUSE Factory arpwatch version 2.1a15-169.5 and prior versions. openSUSE Leap 15.2 arpwatch version 2.1a15-lp152.5.5 and prior versions. (CVE-2021-25321) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25321 https://lists.suse.com/pipermail/sle-security-updates/2021-June/009098.html https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/Y7SKTH3533HITV3EN436RULMJP2HHQND/ ======================== Updated package in core/updates_testing: ======================== arpwatch-2.1a15-21.2.mga8 from SRPM: arpwatch-2.1a15-21.2.mga8.src.rpm
Keywords: feedback => (none)Assignee: nicolas.salguero => qa-bugs
MGA8-64 Plasma on Lenovo B50 No installation issues. Checked the changes on /etc/sysconfig/arpwatch as per bug 6329 are still there: OK. At CLI: # systemctl start arpwatch # systemctl -l status arpwatch ● arpwatch.service - LSB: The arpwatch daemon Loaded: loaded (/etc/rc.d/init.d/arpwatch; generated) Active: active (running) since Sat 2021-11-20 11:49:57 CET; 15s ago Docs: man:systemd-sysv-generator(8) Process: 16726 ExecStart=/etc/rc.d/init.d/arpwatch start (code=exited, status=0/SUCCESS) Tasks: 1 (limit: 9402) Memory: 708.0K CPU: 53ms CGroup: /system.slice/arpwatch.service └─16735 arpwatch -i wlp9s0 -n 192.168.2.0/24 -u arpwatch -e root -s root (Arpwatch) -f /var/lib/arpwatch/arp.dat nov 20 11:49:57 mach5.hviaene.thuis systemd[1]: Starting LSB: The arpwatch daemon... nov 20 11:49:57 mach5.hviaene.thuis systemd[1]: Started LSB: The arpwatch daemon. nov 20 11:49:57 mach5.hviaene.thuis arpwatch[16726]: Starting arpwatch: [ OK ] nov 20 11:49:57 mach5.hviaene.thuis arpwatch[16735]: Running as uid=973 gid=964 nov 20 11:49:57 mach5.hviaene.thuis arpwatch[16735]: listening on wlp9s0 nov 20 11:50:02 mach5.hviaene.thuis arpwatch[16735]: new station 192.168.2.5 b4:6d:83:0d:0c:14 nov 20 11:50:02 mach5.hviaene.thuis arpwatch[16735]: new station 192.168.2.1 3c:7c:3f:d5:d0:af Then checked the user configuration as in bug 6329 # ps -e | grep arpwatch | grep -v grep 16735 ? 00:00:00 arpwatch # grep ^[NUG] /proc/16735/status Name: arpwatch Umask: 0022 Ngid: 0 Uid: 973 973 973 973 Gid: 964 964 964 964 Groups: 964 NStgid: 16735 NSpid: 16735 NSpgid: 16726 NSsid: 16726 NoNewPrivs: 0 # grep arpwatch /etc/passwd arpwatch:x:973:964:system user for arpwatch:/var/lib/arpwatch:/bin/sh All looks consistent and OK.
Whiteboard: (none) => MGA8-64-OK
Validating. Advisory in Comment 10.
CC: (none) => andrewsfarm, sysadmin-bugsKeywords: (none) => validated_update
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0515.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED