Continuing the discussion from Debian-10-minimal Configuration:
If I’m reading this correctly, gpg keys for dom0 updates aren’t validated on non-Fedora updateVMs, creating a situation where an adversary can tamper with dom0 updates. (By blocking or modifying?)
Since a QSB about RPM and validation issues was made, shouldn’t there be a QSB-level warning to users regarding this vulnerability that affects dom0? This sounds serious and potentially widespread, since I imagine many people switch from Fedora without knowing this.
No, this is just about verifying the metadata, not the packages themselves. Since this doesn’t affect package-signing, a maliciously-modified package would still fail to pass the signature check and be rejected, as usual.
As for blocking updates, I’m not certain. My understanding is that blocking updates has historically been possible on Fedora, which is why we’ve recommended updating over Tor. Perhaps @Demi can comment more on this.
Given the above, it’s not as serious you were thinking. Nonetheless, as always, if a QSB is warranted, the Qubes Security Team will issue one. They are aware of the issue.
If you take a look at the issue linked above and the comments on it, it doesn’t just affect people who have switched from Fedora. It affects everyone who hasn’t manually added repo_gpgcheck=1 to their repo defs, so basically everyone.
1 Like
Okay, thank you for clarifying. I only glanced over the thread as I’m allergic to Github, being non-technical and all.
I remember a thread with you about metadata and blocking, so knowing that an adversary wouldn’t be able to modify packages is reassuring.
Edit: Found the threads I mentioned in case anyone’s interested in the metadata issue:
https://groups.google.com/g/qubes-users/c/95S9I1gaBYY/m/g1e0E9etCAAJ
https://groups.google.com/g/qubes-users/c/SbLGJ1CWAWw/m/zGF81YnxAgAJ
Quote by @Tasket:
I hate to break that feeling, but Fedora is unique in that it doesn’t
sign its repo metadata, and sadly that is what matters. They put a
bandaid on it by fetching more hashes via https… so the update
security in Fedora is based on the strength of https. That is bad, as
https can be subverted by resourceful attackers.What this potentially allows is an attacker to blind Fedora systems to
specific package updates, where the systems appear to retrieve updates
normally without the users being aware that particular packages with
known vulnerabilities have been held back.Note that RHEL and Centos do sign their repomd.xml. So we’re looking
at some kind of decision made either by Red Hat’s marketing department
(keep Fedora off RHEL’s expensive turf) or by some idea that Fedora is
not for serious mission critical environments, or both.So this is a sizable hole in Qubes security. The best advice I can give
is to avoid using Fedora templates and pay attention to Qubes Security
Bulletins when they mention which dom0 components will be updated (and
pay close attention when running qubes-dom0-update to look for the
mentioned components).
Fedora is unique in that it doesn’t sign its repo metadata
Apparently this may have changed recently, since #6275 appears to be all about verifying signed Fedora repo metadata. Again, I defer to @Demi for clarification on this point.
Edit: Oh, wait. I think I see what’s going on now: It’s the Qubes repositories that have signed metadata. The Fedora repos may still not. And the main point of this issue is about being able to verify the signed Qubes repo metadata. At first, that wasn’t working with any UpdateVMs. Then @Demi fixed it for Fedora UpdateVMs, and now it remains to be fixed for non-Fedora UpdateVMs.
1 Like
Thanks for the ping @adw!
I did recently disclose some RPM vulnerabilities but they do not affect the security of Qubes OS. As @adw stated, dom0’s RPM would reject the altered package. Furthermore, rpmcanon is being deployed as a mitigation against future vulnerabilities in RPM.
1 Like
@adw asked if Fedora VMs are needed.
The only time I use them is to test other peoples problems. Other it’s
Debian, Ubuntu and BSD.
I do have one clearnet domain where I use a vanilla Fedora, but that’s
for historical reasons.
The Fedora repos may still not. And the main point of this issue is
about being able to verify the signedQubes repo metadata. At
first, that wasn’t working with any UpdateVMs. Then @Demi fixed it
for Fedora UpdateVMs, and now it remains to be fixed for non-Fedora
UpdateVMs.
@Demi in addition I got the impression that using the qubes updater this
always works even if a debian updatevm is used, because the updater
“works around” the issue. Can you confirm?
@adw thank you for the PSA. I never used the qubes updater because it
seemed using the command line was much faster and less error prone. Now
I understand that it is critical to use the qubes updater not only
because of this particular issue but also because the Qubes team might
push some changes exclusively via qubes updater (as in I wouldn’t get
those just by calling qubes-dom0-update) – correct?
possible to use only Debian VMs
I am doing so for over a year without any issues.
Or is there still something for which you have to keep at least one
Fedora VM around?
Qubes Builder
We’re working on a post to clarify this right now, but that’s basically right. It’s not that we would silently push such changes. Rather, from a “public health” perspective, it’s better to send the message that everyone should just update via Salt, because this way we increase the probability that more users will be more secure more of the time. For example, for a given QSB that requires updating via Salt in order to receive the correct security fix, statistically, some non-zero percentage of users will miss or ignore the QSB and continue blindly updating without Salt, thereby missing out on the security fix. If we start moving the status quo to Salt updates as the default recommended update method, we can decrease the incidence of such harm over time. More people will get into the habit of doing Salt updates, so fewer people will accidentally miss out on security fixes.
2 Likes
Just to follow up on this after receiving some information from Marek, there is no bug or vulnerability involved here, aside from the actual one being reported in #6275. Rather, signed metadata verification would just be another extra layer of defense in a process that already has many layers of defenses (like already having a belt and suspenders and deciding whether you want to add another belt or another pair of suspenders). In brief, only the UpdateVM parses the repo metadata; when packages are passed to dom0, the metadata is not. Then Qubes checks the signatures on the packages itself before even letting dnf touch them (and this was recently strengthened due to QSB-067). So, protecting against the threat of maliciously-malformed metadata would improve protection for the UpdateVM, but the UpdateVM is actually already untrusted from dom0’s perspective in the first place. Signed metadata can also make attacks involving metadata manipulation more difficult, but it can’t prevent all the DoS-type update attacks, and there are already other measures in place to help with metadata integrity checking. So, overall, a small but nice extra bit of hardening to have when 4.1 is released.
1 Like
You can build all packages and templates on a Debian based builder too.
You used to be able to build an iso, but I haven’t tried that for some
time.
1 Like
Which BSD domains do you use? I used OpenBSD at one point but gave up after some conflicts on the mailing lists.
openBSD: conflicts on the mailing lists are expected.
I expected constructive feedback, not to be told that the idea of sandboxing a program from the outside was bogus.
It’s a rite of passage being blown out on those fora. If Theo hit you,
wear it with pride. There should be a T shirt.
3 Likes
Hi @unman,
For my qubes-builder AppVM, with the end of fedora-32, I didn’t choose to try fedora-33 but debian-10 as I remembered your above sentence.
But on the first steps of my template building, I see a rpm-base-distribution dependency. In fact, the make install-deps step try to install some packages (ex: perl-Digest-MD5 …) than only exists in rpm repositories, not in Debian repository.
Details:
user@builder:~/qubes-builder$ make install-deps
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package perl-Digest-MD5
E: Unable to locate package perl-Digest-SHA
E: Unable to locate package rpm-build
E: Unable to locate package rpm-sign
E: Unable to locate package rpmdevtools
make: *** [Makefile:1132: install-deps.dpkg] Error 100
user@builder:~/qubes-builder$ cat /etc/debian_version
10.9
The only way I see is updating the Makefile with the good package names (ex: libdigest-md5-file-perl…) for example with the DEPENDENCIES.dpkg makefile variable. I can do this job, but with your sentence I understood that it should work without these changes. I don’t want to do some useless jobs…
So where I’m wrong?
You are not wrong - the Makefile is aimed only at rpm-based
distributions.
If you want to build on Debian (or any other base) then you must find the
native equivalents to these packages.
I do not think that my sentence had the implication you drew.
Thanks for the explanations. I will explore the Makefile change by curiosity…