Anyone who has ever installed fedora virtio-win packages via yum is vulnerable
by Gianni Tedesco
If you have ever installed the
virtio-win package in accordance with the
then your system is vulnerable to a remote root exploit every time you do a yum
upgrade, and will stay like that forever more, until you remove the virtio-win
That is because the instructions tell you to setup a yum repo with the with a
gpgcheck=0… This, essentially, disables all
security and allows a network man-in-the-middle (even a regular old web proxy)
to inject bogus updates every time you do a
dnf upgrade - which will be
nightly if you have installed
This entire process, including exploitation, can happen without dnf providing any hint to the user that it is downloading arbitrary code insecurely over the internet and running it.
What can you do about it?
Turns out that there is not a whole lot you can do about this yet. My best advice to you is to disable this yum repo immediately.
There is a github issue tracking the change required to sign the contents of virtio-win repository.
Windows has a better security culture than Linux
Note, that the windows drivers themselves are signed. That’s because loading windows drivers without signatures is a complete rigmarole so the drivers would be next to useless if they weren’t signed.
But here, the signatures are luring people in to a false sense of security because you may imagine that since all RPM is doing is downloading some opaque blobs which only a guest will install, that as long as the blobs are signed and the windows guest OS verifies them then an end-to-end root of trust is established.
But this is not so, since the Linux host is compromised. All an attacker has to
do is create a new RPM based on the old virtio-win RPMs (including all the
valid signatures) and just add a
%postinstall RPM script which roots the
host. So now it doesn’t matter that the guest is secure, because the host is
compromised. And if the host is compromised then all bets about the integrity
of the guest are off.
If RPM applied its signatures with the same dilligence as Windows update, we probably would not be in this mess.
I also filed a bug against dnf that it insecurely installs code from the internet without so much as a warning message.
DNF does not check TLS certs if you use https! (not true)
Initially I thought that a quick workaround would be to change the repo URL to
https. After all,
fedoraproject.org should be trustworthy.
But according to the DNF developers “DNF is happy with any HTTPS connection, even with a self-signed certificate and a complete redirect to a different server would be unnoticed.”
Apparently there is a plan to solve this but it won’t land before RHEL9 because the user experience would necessarily change if dnf were to check HTTPS certificates.
Of course, there are good historical reasons not to use TLS, it breaks caching. But given todays threat landscape, mirror services may just want to suck up this cost.
Update: provided that
sslverify=1, which is the default, the yum TLS client
will reject any connection that cannot be authenticated and downloads will
Arbitrary remote code execution is arbitrary remote code execution
Merry christmas, happy new year, it’ll soon be 2021, and here’s to another year of telling people that arbitrary remote code execution is arbitrary remote code execution.
You can refer to the virtio-win repo issue as
Originally the title was sloppily written and it implied that all virtio-win packages available on any yum repo had this problem. In fact, the fedora repo is only once such repo. Apparently the RHEL repos do not suffer from this problem. Thanks Cole Robinson for pointing that out.
Thanks to Ken Dreyer and Daniel Mach for clearing up the points about DNF.tags: security - vuln - cve - virtio-win - fedora - redhat - cve-2020-29665