| Summary: | libvirt new security issue CVE-2021-3631 | ||
|---|---|---|---|
| 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: | bequimao.de, davidwhodgins, mageia, ouaurelien, sysadmin-bugs |
| Version: | 8 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA8-64-OK | ||
| Source RPM: | libvirt-7.0.0-2.mga8.src.rpm | CVE: | |
| Status comment: | |||
| Attachments: |
Addendum: Log of Install/Upgrade of package list # dnf-qarepo.sh
Test of libvirt-guests.service Log of # dnf history undo <transaction no.> Excerpt of system-upgrade, checks of libvirt-guests |
||
|
Description
David Walser
2021-07-13 03:41:32 CEST
David Walser
2021-07-13 03:41:42 CEST
Status comment:
(none) =>
Fixed upstream in 7.5.0 Assigning to Thierry, the active maintainer of 'libvirt'. Assignee:
bugsquad =>
thierry.vignaud patch added in mga8:
src:
- libvirt-7.0.0-2.1.mga8CC:
(none) =>
mageia libvirt-devel-7.0.0-2.1.mga8 libvirt0-7.0.0-2.1.mga8 wireshark-libvirt-7.0.0-2.1.mga8 libnss_libvirt2-7.0.0-2.1.mga8 libvirt-docs-7.0.0-2.1.mga8 libvirt-utils-7.0.0-2.1.mga8 from libvirt-7.0.0-2.1.mga8.src.rpm
David Walser
2021-07-19 21:55:52 CEST
Status comment:
Fixed upstream in 7.5.0 =>
(none) Installation of the update causes mgaapplet to hang waiting for
/bin/systemctl --quiet try-restart libvirt-guests.service
# systemctl status libvirt-guests.service
● libvirt-guests.service - Suspend/Resume Running libvirt Guests
Loaded: loaded (/usr/lib/systemd/system/libvirt-guests.service; enabled; vendor preset: disabled)
Active: deactivating (stop) since Mon 2021-07-19 16:00:21 EDT; 9min ago
Docs: man:libvirtd(8)
https://libvirt.org
Main PID: 2208 (code=exited, status=0/SUCCESS); Control PID: 98418 (libvirt-guests.)
Tasks: 3 (limit: 3549)
Memory: 4.1M
CPU: 44ms
CGroup: /system.slice/libvirt-guests.service
├─98418 /usr/bin/sh /usr/libexec/libvirt-guests.sh stop
└─98425 virsh connect
Jul 18 23:54:25 hodgins.homeip.net systemd[1]: Starting Suspend/Resume Running libvirt Guests...
Jul 18 23:54:25 hodgins.homeip.net systemd[1]: Finished Suspend/Resume Running libvirt Guests.
Jul 19 16:00:21 hodgins.homeip.net systemd[1]: Stopping Suspend/Resume Running libvirt Guests...
After using "killall virsh", mgaapplet continued and showed the updated config
files dialog.CC:
(none) =>
davidwhodgins Advisory: ======================== Updated libvirt packages fix a security vulnerability: libvirt: insecure sVirt label generation (CVE-2021-3631). References: - https://bugs.mageia.org/show_bug.cgi?id=29252 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3631 - https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/WMXIHZROH2MHK2ATU7LWCID54SCKZA7Z/ ======================== Updated packages in core/updates_testing: ======================== lib(64)virt-devel-7.0.0-2.1.mga8 lib(64)virt0-7.0.0-2.1.mga8 wireshark-libvirt-7.0.0-2.1.mga8 lib(64)nss_libvirt2-7.0.0-2.1.mga8 libvirt-docs-7.0.0-2.1.mga8 libvirt-utils-7.0.0-2.1.mga8 from SRPM/ libvirt-7.0.0-2.1.mga8.src.rpm CC:
(none) =>
ouaurelien
Ulrich Beckmann
2021-07-20 22:16:56 CEST
CC:
(none) =>
bequimao.de Installed the package list in an instance which is a clone of Mageia 8 with running Virt-Manager. libvirt-utils is an upgrade here, not an install. No problem found during installation, no stalling. [root@mga8-tst2 ~]# journalctl -ab | grep libvirt Jul 21 15:49:05 mga8-tst2 dnsmasq[1471]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses Jul 21 15:49:05 mga8-tst2 dnsmasq-dhcp[1471]: read /var/lib/libvirt/dnsmasq/default.hostsfile Jul 21 15:51:03 mga8-tst2 systemd[1]: libvirtd.service: Succeeded. Jul 21 15:51:03 mga8-tst2 systemd[1]: libvirtd.service: Unit process 1471 (dnsmasq) remains running after unit stopped. Jul 21 15:51:03 mga8-tst2 systemd[1]: libvirtd.service: Unit process 1472 (dnsmasq) remains running after unit stopped. Jul 21 15:58:35 mga8-tst2 [RPM][3193]: erase libvirt-utils-7.0.0-2.mga8.x86_64: success Jul 21 15:59:54 mga8-tst2 [RPM][3193]: install wireshark-libvirt-7.0.0-2.1.mga8.x86_64: success Jul 21 15:59:57 mga8-tst2 [RPM][3193]: install libvirt-utils-7.0.0-2.1.mga8.x86_64: success Jul 21 15:59:58 mga8-tst2 [RPM][3193]: install libvirt-docs-7.0.0-2.1.mga8.x86_64: success Jul 21 15:59:59 mga8-tst2 [RPM][3193]: install lib64nss_libvirt2-7.0.0-2.1.mga8.x86_64: success Jul 21 16:00:00 mga8-tst2 [RPM][3193]: erase libvirt-utils-7.0.0-2.mga8.x86_64: success Jul 21 16:01:05 mga8-tst2 [RPM][3193]: install wireshark-libvirt-7.0.0-2.1.mga8.x86_64: success Jul 21 16:01:05 mga8-tst2 [RPM][3193]: install libvirt-utils-7.0.0-2.1.mga8.x86_64: success Jul 21 16:01:05 mga8-tst2 [RPM][3193]: install libvirt-docs-7.0.0-2.1.mga8.x86_64: success Jul 21 16:01:05 mga8-tst2 [RPM][3193]: install lib64nss_libvirt2-7.0.0-2.1.mga8.x86_64: success [root@mga8-tst2 ~]# [root@mga8-tst2 ~]# systemctl list-units --all | grep libvirt libvirt-guests.service loaded inactive dead Suspend/Resume Running libvirt Guests libvirtd.service loaded inactive dead Virtualization daemon libvirtd-admin.socket loaded active listening Libvirt admin socket libvirtd-ro.socket loaded active listening Libvirt local read-only socket libvirtd.socket loaded active listening Libvirt local socket [root@mga8-tst2 ~]# Ulrich Specifically, what I'm suggesting that the libvirt-guests.sh stop needs to be fixed to only run the virsh comand if there are guests to stop. Leaving mgaapplet hanging while installing the update is not ok. I'd previously used libvirt, and while I'd removed the guests, I forgot to disable the service. (In reply to Dave Hodgins from comment #4) > Installation of the update causes mgaapplet to hang waiting for > /bin/systemctl --quiet try-restart libvirt-guests.service > I guess it is missing rights. Please confirm # cat /etc/group | egrep 'libvirt|kvm|qemu' kvm:x:996:qemu qemu:x:969: libvirt:x:469:bequimao I added the group libvirt manually. The units with a running guest look like this # systemctl list-units --all | grep libvirt libvirt-guests.service loaded inactive dead Suspend/Resume Running libvirt Guests libvirtd.service loaded active running Virtualization daemon libvirtd-admin.socket loaded active running Libvirt admin socket libvirtd-ro.socket loaded active running Libvirt local read-only socket libvirtd.socket loaded active running Libvirt local socket $ egrep 'libvirt|kvm|qemu' /etc/group
kvm:x:961:qemu,dave
qemu:x:960:dave
$ systemctl list-units --all | grep libvirt
libvirt-guests.service loaded active exited Suspend/Resume Running libvirt Guests
libvirtd.service loaded inactive dead Virtualization daemon
libvirtd-admin.socket loaded active listening Libvirt admin socket
libvirtd-ro.socket loaded active listening Libvirt local read-only socket
libvirtd.socket loaded active listening Libvirt local socket
$ systemctl -l --no-pager status libvirtd.service
● libvirtd.service - Virtualization daemon
Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Wed 2021-07-21 13:38:54 EDT; 1 day 2h ago
TriggeredBy: ● libvirtd.socket
● libvirtd-admin.socket
● libvirtd-ro.socket
Docs: man:libvirtd(8)
https://libvirt.org
Main PID: 2378 (code=exited, status=0/SUCCESS)
CPU: 811ms
Jul 21 13:36:54 hodgins.homeip.net systemd[1]: Starting Virtualization daemon...
Jul 21 13:36:54 hodgins.homeip.net systemd[1]: Started Virtualization daemon.
Jul 21 13:36:55 hodgins.homeip.net libvirtd[2378]: libvirt version: 7.0.0
Jul 21 13:36:55 hodgins.homeip.net libvirtd[2378]: hostname: hodgins.homeip.net
Jul 21 13:36:55 hodgins.homeip.net libvirtd[2378]: internal error: Failed to apply firewall rules /usr/sbin/iptables -w --table filter --insert LIBVIRT_INP --in-interface virbr0 --protocol tcp --destination-port 67 --jump ACCEPT: iptables: No chain/target/match by that name.
Jul 21 13:38:54 hodgins.homeip.net systemd[1]: libvirtd.service: Succeeded.
Note that installing the update, which runs as root is what triggered the hangup. Created attachment 12871 [details]
Addendum: Log of Install/Upgrade of package list # dnf-qarepo.sh
Created attachment 12872 [details]
Test of libvirt-guests.service
Meanwhile I cloned and installed a MGA8 image to the test installation.
libvirt-guests.service was unknown to me before.
I configured it to shutdown and to resume any running guest at boot. So far everything works fine. No regression found, and I would give it an ok.
@ David: If libvirt-guests.sh shutdowns and resumes guests that are not owned by root, it needs the rights accordingly.
Best regards, Ulrich
Created attachment 12876 [details]
Log of # dnf history undo <transaction no.>
Sorry, my guesses proved to be wrong. And of course, the group libvirt has nothing to do with the rights of root.
I ran into the same issue, when I tried to cleanup with # dnf history undo ...
There was no running guest, and libvirt-guests.service enabled. The script stalled, and I had to kill the process in order to finish the transaction.
Note that the error occurred when running the previous version libvirt-utils-7.0.0-2.mga8.x86_64 (downgrade). So it is a bug, but no regression.
Best regards,
Ulrich
While it is not a regression, so would normally be ok to push the security
update and open a new bug report, the impact of the problem is such that I'm
not ok with pushing the update as is.
The specific problem occurs when the libvirt-utils postinstall scriptlet
runs /usr/share/rpm-helper/add-service libvirt $1 libvirt-guests, which runs
/bin/systemctl --quiet try-restart "$unit"
In /usr/lib/systemd/system/libvirt-guests.service it runs ...
/usr/libexec/libvirt-guests.sh stop
It has a function ...
run_virsh() {
local uri="$1"
shift
if [ "x$uri" = xdefault ]; then
virsh "$@" </dev/null
else
virsh -c "$uri" "$@" </dev/null
fi
}
The problem is that virsh cannot connect and waits indefinitely.
Either it needs to be modified not to call virsh if the libvirtd service is
enabled, but no guests are running, or the program virsh needs to be modified
to handle the state.
Opinion?
I tried now to reproduce the bug under Fedora 34. libvirt-guests.service is provided there by libvirt-client-0:7.0.0-4.fc34.x86_64 libvirt-client-0:7.0.0-6.fc34.x86_64 So I enabled the service, and the idea was to downgrade libvirt-client with running guest, and later upgrade again without. The script stalled during downgrade (with running guest!) and I had to kill the script again. The subsequent upgrade (without guest!) however worked fine. No point to open a bug report on Fedora, as nobody would spend time on an error that occurred during downgrade. So we can't expect that the bug will be resolved in reasonable time, and as there is no regression my vote is to set the current bug report to "ok" and validate it. Best regards, Ulrich openSUSE has issued an advisory for this today (August 10): https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/H5E4Y5JNZAR2C5I2WQMIIPVYTGLK5SBC/ As for the issue being discussed, basically this package is synced with Fedora, so we are unlikely to fix it until they do. Someone should report it to them. I'm not ok with an update that may require a user to run "killall virsh" as root, just to have the update install ok. Keep in mind that this bug would/will be a release blocker for upgrading from Mageia 8 to 9. If it cannot be fixed without possibly requiring root user intervention during installation of an update, I'd rather obsolete ... $ urpmq --whatrequires-recursive libvirt-utils|sort -u cockpit-machines gnome-boxes koji-vm libvirt-java libvirt-java-devel libvirt-utils systemtap-runtime-virthost virt-install virt-manager due to the unfixed security update. (In reply to David Walser from comment #17) > openSUSE has issued an advisory for this today (August 10): > https://lists.opensuse.org/archives/list/security-announce@lists.opensuse. > org/thread/H5E4Y5JNZAR2C5I2WQMIIPVYTGLK5SBC/ > > As for the issue being discussed, basically this package is synced with > Fedora, so we are unlikely to fix it until they do. Someone should report > it to them. openSUSE Leap 15.2 is not the current version. I tried to reproduce the error under Fedora, but the upgrade worked there. Subversion no. there is higher - 7.0.0-6. So we might test that version. (In reply to Dave Hodgins from comment #18) > I'm not ok with an update that may require a user to run "killall virsh" as > root, just to have the update install ok. > > Keep in mind that this bug would/will be a release blocker for upgrading from > Mageia 8 to 9. > > If it cannot be fixed without possibly requiring root user intervention > during > installation of an update, I'd rather obsolete ... > $ urpmq --whatrequires-recursive libvirt-utils|sort -u > cockpit-machines > gnome-boxes > koji-vm > libvirt-java > libvirt-java-devel > libvirt-utils > systemtap-runtime-virthost > virt-install > virt-manager > > due to the unfixed security update. Not a release blocker, but a notification under errata. Do not forget that your finding was accidental, as you "forgot" to disable libvirt.guests. I actually use virt-manager, and so do others. But I never used libvirt.guests. Obsoleting it would be a blow to me. Setting the bugreport to ok as discussed in the QA meeting of 12-08-2021. I will watch the libvirt.guests issue in MGA 8 and Cauldron. Ulrich Whiteboard:
(none) =>
MGA8-64-OK Validating the update despite my misgivings. Hopefully it doesn't cause problems. Advisory in comment 5. Keywords:
(none) =>
validated_update
Thomas Backlund
2021-08-14 12:30:29 CEST
Keywords:
(none) =>
advisory An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0399.html Resolution:
(none) =>
FIXED Created attachment 13589 [details]
Excerpt of system-upgrade, checks of libvirt-guests
I tested now a # dnf system-upgrade from Mga8 to Cauldron with libvirt-guests enabled and a running guest VM.
The whole transaction went through successfully, which was the scope of the test.
However, on reboot libvirt-guests and the VM where broken. Virt-Manager itself was operational. Tested with a second VM.
I think, a reasonable user would shut down the guests and backup them, if production VMs are involved. So I think, no further investigation of failure needed.
Best regards,
Ulrich
|