The xz package that has already entered the current F40 pre-release versions/variants and rawhide contains malicious code.
This does NOT affect users of the Fedora releases (F38, F39 are thus not affected), but all users who use already F40 pre-release versions/variants or rawhide shall read this:
Be aware that this is CVE criticality 10: this is the highest risk factor.
Also be aware that the header of the RH article contains an error: the header of the article refers to “F41 and rawhide”, but the article content refers to “F40 and rawhide”. The latter is correct.
The article should contain sufficient information to respond properly.
The below update 5 marks the final update: users no longer need to follow this page but they can consider the issue solved once they conducted the below steps:
Update 5: state as of 1.4.24, 18:00 UTC-0/GMT is in short (compared to update 4, only the rawhide point was changed):
→ if you have any F40 or rawhide installation, it is suggested to follow the updates on the RH blog article, and if you want also the devel mailing list. You should also review this topic daily: we will update it at least once a day to contain a summary, likely more often. Also, if there are updates, feel free to post them yourself here.
→ Rawhide (currently sometimes referred to as “F41”) installations have to be assumed affected & vulnerable: Rawhide installations have to be fixed the same way as F40
→ F40 installations potentially have installed the malicious packages (the affected “testing” repo seems enabled by default on F40 since its still pre-release), in some cases the malicious code might be broken but in some not - but it is nevertheless suggested in any case to conduct a mitigative action just to be sure: do a dnf update --refresh to get the fix for the vulnerability through your normal updates - the fix (=revert of the malicious code) is already in stable!
→ F40 users can check if they have/had a malicious version installed with dnf history info xz (feel free to grep: dnf history info xz | grep xz ) and then compare the output xz versions with the list of affected builds here. Silverblue/Kinoite users can use rpm -q xz instead, but this only outputs the current version, not the history - so it won’t help if you already reverted the vulnerability. (maybe someone can let me know the rpm-ostree counterpart of dnf history info xz?)
→ so far F40 Silverblue/Kinoite users should also do an update: rpm-ostree refresh-md; rpm-ostree upgrade
→ reboot after updating to ensure that all running processes are restarted/replaced with the fixed version!
→ for users of toolbox: at the best, pull the latest version and restart any containers you were running; if that is for some reason not possible, do dnf update --refresh in all toolboxes
First of all, ensure that no updates are started: then check if the corrupted xz has been already introduced: dnf list xz --installed → 5.6.0 and 5.6.1 are affected. If you have an older version, ensure that xz is NOT updated, and wait until the situation has been clarified. If you have any of the two, the only “general suggestion” I can make at this time is to set this system offline, don’t use it and wait for further notice, or reinstall Fedora completely and don’t reuse anything executable: there is not sufficient reliable information at this time, so that’s the only thing that is widely for sure.
Do whatever is less invasive for you. In any case, if you are affected, keep following the problem and further publications.
Supplement: Read all updates below and in the devel mailing list before implementing anything of this…
I do not use Silverblue and cannot help much. If xz is installed by default with rpm-ostree, you should behave correspondingly but check which command with rpm-ostree equals the mentioned dnf command. If xz is installed by other means, I tend to assume that the impact will be less, but I do not know how to respond at this time, so the suggestion would be to cut the system from the Internet, avoid updates, and wait for further notice - or follow the re-install advice, depending on what is easier / less invasive for you.
Supplement: Read all updates below and in the devel mailing list before implementing anything of this…
Please dont call / invoke xz if you don’t know if the version is malicious. It is not yet much information available, but with calling xz, you might invoke the malicious code yourself. So use dnf or rpm instead.
(Sorry for deleting your comment @ersen , but the command could be dangerous and should be avoided until we know more)
Some new information / clarification from @rjones → it seems that the vulnerability was only very shortly in the testing for F40 and thus unlikely to be installed. Some response is nevertheless suggested:
There was an F40 change that was vulnerable but it was in testing only
briefly. After disabling ifuncs we (accidentally) were not vulnerable
in F40. So the RH article is kind of correct.
I still recommend everyone updating to the Epoch: 1 package if they're
on F40 or F41.
Also if you're on F41 and/or think you might have installed the
vulnerable xz anywhere, note that the exploit has not been fully
analyzed and no one really knows what it could do. I'm currently
reinstalling a couple of machines from scratch and have regenerated
my SSH keys.
A list of all affected packages, including a deletion script in case, are also in the devel mailing list. Affected users might review Rich’s comments to get some overview about if they are affected, what they are up against and what to do.
I hope I’m not being too paranoid, but I wonder if even the versions of xz that currently appear to be safe with respect to this malware will be reviewed to make sure that they don’t contain anything else, since what has been produced by those GitHub accounts cannot be trusted at the moment.
No worries. There is review and more investigation as well. And there is already a further discussion how to proceed with xz in general, since the trustworthiness of the xz-related upstream is currently questioned, as you already indicated.
At this time, we know that this issue is not limited to Fedora: there will be further investigations as well, not just in Fedora.
The CVE on itself will be also further analyzed from many parties in the subsequent days. It’s a factor 10 CVE… this on itself will draw attention to it from many sides, especially if the initial CVE classification from RH gets confirmed.
There are a lot of questions at the moment, and it will take some time until they can be sufficiently answered, and then consequences can be derived. For now, the immediate action that is necessary is to mitigate/avoid the impact on systems in production environments.
this was nice wakeup today yesterday upgraded F40 silverblue beta full system, wake up and bios datawipe and back to f39 silverblue. I have to thank you all for good information and updates on issues
