i have in bios options to enable full datawipe and clear TPM owners/keys etc so usually i use this if there is even small thing that might infect something so i cleared all TPM owners and keys and enabled bios data wipe reboot it clears all and prompts to start bios datawipe just hit yes and yes and restart all cleared
1 Like
More on this published in the Fedora Magazine:
Can you put this in announcement section.
Correction / clarification to the top post and the magazine post at this time: updates-testing is enabled BY DEFAULT on Fedora 40, because itâs a pre-release.
Based on Richardâs list of potentially vulnerable builds, I believe a potentially-vulnerable build was in F40 updates-testing for approximately three days, between March 2 and March 6:
[adamw@xps13a bodhi (develop %)]$ koji list-history --utc --tag=f40-updates-testing --package=xz | grep into
Sat Mar 2 00:42:20 2024 xz-5.6.0-2.fc40 tagged into f40-updates-testing by bodhi
Tue Mar 5 00:16:32 2024 xz-5.6.0-3.fc40 tagged into f40-updates-testing by bodhi
Availability in the public repo lags those timestamps somewhat, because once the package is tagged it doesnât really reach the repo till the next time we compose it, which happens once a day. So it would have appeared in the repo some time after 00:42 on March 2, and been replaced by the not-known-vulnerable 5.6.0-3.fc40 some time after 00:16 on March 5.
Anyone running Fedora 40 who updated normally during that time may well have received the potentially-vulnerable build.
7 Likes
Thanks for the information! I added it to the top post.
If I understand Richard correct, he tried to fix what then appeared as a bug before pushing the packages to testing, and so the malicious packages have entered testing, but the malicious code is likely to be broken on F40, right?
I updated the headline correspondingly to your information and that of Rich (let me know if I shall change something).
@jflory7 can you correct the magazine article? It contains the following:
As Adam pointed out, F40 pre-release has enabled the testing repos by default, so it is not opt in.
1 Like
I see you closed the other topic, but I think the situation is different for silverblue though? Silverblue handles testing somewhat different. If you want to receive testing updates you have to rebase to fedora/40/x86_64/testing/silverblue instead of fedora/40/x86_64/silverblue. So shouldnât silverblue 40 be fine?
Please correct me if I am wrong.
I have rebase using this
So i am thinking to change reinstall as this was a core system which was infected.
I am no Silverblue expert, but generally their testing and stable repos should be enabled/disabled/handled the same way: F40 contains testing repos enabled because it is pre-release. F38 and F39 have them disabled because they are releases. Thus, if F40, then do update: the related update of xz is already stable anyway. There should be no need to adjust your repos. Thus, just update, but do it with --refresh to ensure the database is refreshed and thus all current updates are contained.
@adamwill @siosm can you maybe say something about this? Is there anything else to consider for Silverblue/Kinoite other than doing updates with rpm-ostree rather than with dnf?
Sure updating sounds like a good idea anyway. I am just interested in whether we where even affected.
The equivalent of --refresh and update on atomic desktop would be:
rpm-ostree refresh-md
rpm-ostree upgrade
I received the following update:
xz 5.4.6-1.fc40 -> 1:5.4.6-3.fc40
xz-libs 5.4.6-1.fc40 -> 1:5.4.6-3.fc40
@frankjunior A reinstall sounds a bit excessive, there is already an update available. For as far as we know the vulnerability only affects sshd, something you probably do not have publicly accessible on a desktop system. But that is just my opinion.
1 Like
For now, we have to ensure that the impact is minimized and mitigated. Everything else comes later.
So for now, the update should do the work for both mutable and immutable desktops, unless something else comes up.
The major question is if xz is installed through rpm-ostree or not in the immutable desktops. But because of its use cases, I tend to assume yes. In any case, for now, we have to assume the worst, but that leads back to the update 
However, I am not sure if there need to be further considerations with some flatpaks or so. But this is something we cannot solve here immediately. I would wait for some Silverblue/Kinoite developers to make a comment about differences. Cleaning your tree (updateâŚ) is the major mitigation for now.
Btw, thanks for the information about the rpm-ostree command!
Slight addition: just to minimize any impact: users of toolbox might also update their toolboxes!!!
1 Like
No, that is not correct, as explained here and here. We have already asked Red Hat to investigate and fix the blog post. This is still an evolving situation; apologies for the confusion as we sort this out.
2 Likes
Thanks Michael, I update the top post.
Supplement: top post updated; feel free to let me know if further adjustments are necessary
2 Likes
Some rpm-ostree history can be retrieved by rpm-ostree ex history --all. On Fedora Atomic Rawhide Kinoite and Silverblue,xz-5.6.0 was included in the base image 20240301 and after. Fedora 40 (not testing) does not appear to include any version of xz-5.6.x in its base image.
2 Likes
There is no explicit evidence at this time if all F40 Silverblue/Kinoite have testing disabled/enabled by default. Especially since the mutable F40 variants have it enabled by default (as F40 is not yet a release), we have to assume that there are Silverblue/Kinoite F40 installations out there with testing enabled by default and potentially with a malicious xz build installed. It would be cool if that proves wrong, but better we mitigate the vulnerability without the need rather than vice versa. So I leave the update suggestion for Silverblue/Kinoide for now, it can only improve the situation but not cause any harm. Hopefully, we have some dedicated Silverblue/Kinoite research soon.
Thanks! <deleted>
Supplement: ex seems to indicate experimental features according to man rpm-ostree. Since we distribute this to many people (and many potentially differing installations) and since I cannot estimate âhow experimentalâ it is, I tend to not use it. But still thanks for the suggestion 
Maybe rpm-ostree is not yet provided with a comparable function.
rpm-ostree ex history --all wonât show the installed xz version though. For that you need to do some bash magic which I shared in the previous discussion.
But sure, probably best to advice updates while we are not 100% sure. They should be automatically installed on most atomic systems anyway, the user only needs to reboot.
Forgot to mention in the previous post, but the update isnât applied if the user doesnât reboot!
1 Like
Indeed a good point! I put it to the top. That is not just interesting for Silverblue: also on other Fedoras, running processes might not be replaced/restarted immediately when updated. A reboot is always on the safe side.
1 Like