I was wondering how do these GPG vulnerabilities (https://gpg.fail/) affect Qubes and more specifically Dom0 updates. Do they even pose any problem at all ? From my limited understanding most of them seem to try to fool the user by messing with the text output in the terminal but it is unclear to me if the package update mechanism would swallow it as well. On one hand the Qubes updates architecture’s inner-workings may mitigate that but on the other it seems to me that the older fedora 37 (on 4.2.4) and GPG package may be relevant in this specific case.
In a scenario like Power on > connect to the wifi > immediately update dom0 (trough GUI)> reboot > update fedora templates (sysnet and usb)> update whonix templates > update debian templates:
Could one still rely on the updater’s verification mechanism or will he be forced to pray that the the servers don’t try anything funny ? Is there any other mitigation a not very technical user could take ?
I believe that gpg is used in RPM, not RPM as a whole but since there is signature (spoofing?) and Remote Code Execution (in dom0?) potentially on the list (and a dozen other vulns I don’t understand), I thought I’d rather ask than assume.
Unfortunately there is no viable answers in that other discussion. So, after some further digging :
One vulnerability seems to affect the Qubes ISO verification method (fooling the user)
One seems to affect detached signatures (which IIRC can be used to verify the ISO as well) and I am concerned about it working against the update mechanism.
One is a potential RCE but I don’t understand how it actually works in practice and how to not fall for it.
No idea about all the (11?) others.
#1: I am not seeking to verify a Qube ISO RN and know I would have to lookout for “armor header error” if I did. It still gives a valid signature so perhaps it would be able to fool the update manager in the context of updates ?
#2: Does worry me a lot.
Here (I will voluntarily write “h-ttps” because I am limited to 2 links per post, sorry), h-ttps://docs.fedoraproject.org/en-US/reproducible-builds/ , it says that RPM packages don’t use detached signatures but clicking on this github discussion (h-ttps://github.com/rpm-software-management/rpm/issues/1482) it says that they are used to verify metadata repository and checksums. Another post says it is not needed but I have no idea what the metalink stuff means.
Here (oss-sec: Re: Many vulnerabilities in GnuPG) it is said that " The Fedora Linux family of distributions already doesn’t use GnuPG in the critical path anymore. RPM and DNF have been switched to SequoiaPGP for quite some time. That change was inherited by Red Hat
Enterprise Linux 10 as well. This is why we have PQC support in our PGP stuff…" But does this apply to f37 dom0? Seems also if not only relevant for #3.
Here (oss-sec: Re: Many vulnerabilities in GnuPG --) this person (which is @Demi if I am not mistaken) says “I think most software update tools use msg.txt directly and so are
not vulnerable, unless the signature uses text mode in which case
a different attack might work. Can you see if APT is vulnerable?”. I worry about the “unless” part and misunderstanding some context.
#3-4: I have nothing to add.
In the past, there have been RPM and APT vulnerabilities reported in QSB so there not being one seems pretty reassuring unless I am just somewhat early.
I don’t speak Code and just a few words of linux terminal, hence my struggles and why my “analysis” here is likely worthless (just clarifying for other users).
I chose to continue this discussion here as its scope is specifically on the updates and not on if one can continue his normal daily usage in qubes. Sorry for any weird formatting.
Regarding #2, it has been fixed in commit 8abc320, but, looking at the git history, the fix hasn’t been merged yet into release branches. I checked for both 2.4.5 (dom0) and 2.4.7 (fedora 42) versions of gnupg.
I might be wrong however, if somebody knows gnupg better than me, don’t hesitate to correct me.
As far as I can tell there are vulnerabilities for both verification methods, not just hashes.
Luckily, our documentation is written well and the way hash sum verification is described there doesn’t seem to be entirely vulnerable to the nullbyte attack I tried. This is the way we are supposed to use this according to the docs:
$ gpg2 -v --verify Qubes-R4.3.0-x86_64.iso.DIGESTS
gpg: armor header: Hash: SHA512\0\v\rMy test message
gpg: original file name=''
gpg: Signature made Wed 17 Dec 2025 11:34:33 PM UTC
gpg: using RSA key F3FA3F99D6281F7B3A3E5E871C3D9B627F3FADA4
gpg: using pgp trust model
gpg: Good signature from "Qubes OS Release 4.3 Signing Key" [full]
gpg: textmode signature, digest algorithm SHA512, key algorithm rsa4096
Compared to the usage demonstrated in the attack:
$ gpg2 --verify Qubes-R4.3.0-x86_64.iso.DIGESTS
gpg: Signature made Wed 17 Dec 2025 11:34:33 PM UTC
gpg: using RSA key F3FA3F99D6281F7B3A3E5E871C3D9B627F3FADA4
gpg: Good signature from "Qubes OS Release 4.3 Signing Key" [full]
As you can see, message hidden by nullbyte is visible. If it was something long, like a hash sum to fool *sum -c checks, it would’ve been more obvious.
Unfortunately this can only give positive result with people aware of this attack, random user might just ignore long weird value after armor header:
Presenters show even better way to avoid this problem: by using --decrypt with -o you can write the real verified message to a separate file, and then check hashes against this new file. (Which also defeats notsoclear btw)
I still have usb stick unchanged from which I installed Qubes. How do I check if the iso I burned into it is genuine now? I am not familiar with gpg and I only used for verifying Qubes iso, before and after writing it to usb stick
Only good news (to me specifically) are - I did check the bash history on the device I used for creating bootable usb stick for Qubes and I did follow the official documentation
Check the list of vulnerabilities on gpg.fail and decide how bad the situation is for yourself if you want to verify asap. I haven’t checked everything yet. notdash, notsoclear, and nullbyte appear to be solved by --decrypt, minisign-related stuff doesn’t affect gpg.
Okay, here are my unprofessional notes on the vulnerabilities:
TL;DR:
I believe checking an iso via hash sum method is safe if you:
check DIGESTS for \fs, see 3
use patched gpg with --decrypt -o
use a system with only one keyring (see 13 for better explanation)
don’t ignore any gpg warnings
check the output file manually and ensure there are no fake gpg success message (I need help confirming that) (Alternatively, use both --decrypt and --verify commands, you want both to succeed)
check against hashes in the output file
Detached signature is safe if you use patched gpg.
Can anyone chip in and help me figure out how they do noverify?
Full notes:
detached Multiple Plaintext Attack on Detached GPG
Attacks detached signatures
--decrypt is vulnerable
Fixed in 8abc320 (patch unreleased)
filename GPG Accepts Path Separators and Path Traversals
Attacks ANSI-capable shell with a malicious binary as gpg input
Fixed in ad0c6c3, (released?)
Always use a subcommand with gpg
formfeed Cleartext Signature Plaintext Truncated for Hash Calculation
Attacker can MITM cleartext signed messages that contain \f at the end of a line.
Unpatched
\f allegedly rarely used nowadays
Check messages for \f character (might be displayed as ^L)
\f can be hidden using tabs (\t) or newlines (\r), check line width and unnecessary empty lines at the end of a message
malleability Encrypted message malleability checks are incorrectly enforced
phishing-like attack
malformed PGP message can exfiltrate plaintext via signed outputs (you may publish decrypted stuff you never intended to)
will not be fixed
when attacked, gpg2 prints decryption failed: invalid warning
be extremely cautious about gpg warnings
memcpy Memory Corruption in ASCII-Armor Parsing
Attacks gpg-running system via memory corruption using malicious input file
Fixed in 115d138 (patch unreleased)
minisign Trusted comment injection
minisign-specific
notdash Cleartext Signature Forgery in the NotDashEscaped header
Attacker can insert anything after NotDashEscaped line in headers.
Is unpatched
Defeated by --decrypt -o
notsoclear Signature Format Confusion
Attacks cleartext signatures
Is unpatched
Defeated by --decrypt -o
noverify GPG Output Fails To Distinguish Verification Success From Message Content
Attacker can add fake gpg output-mimicking plain text to a file
--verify fails, but --decrypt prints fake success message. Both commands return 0.
User can only trust output to stderr
Will not be fixed
This attack should be obvious if you use --decrypt -o and check output file, but I cannot reproduce it to check
Thanks a lot for the explanations you provided here, especially in your first posts I wouldn’t have found this myself.
Regarding this quote, I believe it is actually referring to “memcpy”, the memory corruption vulnerability (my #3 instead of my #2), apologies.
@ShuosJedao-2 thank you as well, did you check in 4.2.4 or 4.3 ?
I am still eager to learn more about “memcpy” and “detached” or anything regarding the qubes update process as we will all have to update to get the relevant fixes anyways but the lack of noise seems pretty positive. Does anybody know how long would a QSB take to be released (as to know when we are actually in the clear if one doesn’t appear) ?
You can get the hash again from the USB stick and then compare that to the hash of the iso downloaded from website. Then check the downloaded iso against the iso.asc with -v --verify
Then it is genuine if that hash matches the downloaded iso hash (and that verified with the detached signature and hash digest with cli flags added for mitigation)
That’s the best you can get currently other than getting an iso directly from a verified dev
Best of my knowledge is that dom0 has been using qubes-rpm-oxide for updates to help with potential PGP issues like this, and Fedora Templates still have rpm-sequoia and TLS to fall back on.
I do hope the lack of QSB means this won’t be/hasn’t been an issue for updates.
(Note: I’m not a security professional, I’ve just been reading through all this and shared what I’ve seen as more of an inquiry than anything)
