| Summary: | arpwatch new security issue CVE-2021-25321 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | Security | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Sec team <security> |
| Severity: | normal | ||
| Priority: | Normal | CC: | andrewsfarm, davidwhodgins, herman.viaene, nicolas.salguero, sysadmin-bugs |
| Version: | 8 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA8-64-OK | ||
| Source RPM: | arpwatch-2.1a15-21.mga8.src.rpm | CVE: | CVE-2021-25321 |
| Status comment: | |||
|
Description
David Walser
2021-06-29 18:58:41 CEST
David Walser
2021-06-29 18:59:02 CEST
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 openSUSE 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 =>
ASSIGNED 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) 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-bugs
Dave Hodgins
2021-11-20 18:28:25 CET
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 =>
RESOLVED |