Original dev details:
https://tukaani.org/xz-backdoor/
1 Like
I do only mean witch hunting not hunting for the truth.
It is very clear that this case is questioning the current way trust is built and handled over Linux ecosystem.
2 Likes
I had the offending version 5.6.1-1
i just upgraded the system ( also xz to clean version 5.6.1-2)
can i rest assured or should i perform a new clean installation ( from scratch ) of endeavouros?
in another pc ( same problem i fixed by upgrading the system ) the fact that i installed apparmor may lead to some more issues regarding the problam of the xz package
Refer to the last section of the Arch Linux announcement mentioned in this post
It appears that Arch does not link openssh to liblzma, so the attack isnât possible even with the compromised version (5.6.1-1)
However, it is still too early to tell the extent of the attackerâs exploit. The attacker (Jia Tan) has made a lot of commits in a lot of packages over the last 2 years, so reinstalling right now would be kind of pointless since we donât even know what other packages are compromised.
If you truly want to be safe, Iâd start with revoking all the private keys that are stored on the system. And while youâre at it, probably move all your sensitive data elsewhere.
as a casual user, I would like to ask⌠what exactly are private keys?
How exactly should I do that?
Iâm sure you are familiar with the concept of a physical keyâas in the tool you insert into a padlock in order to unlock it. Well, the same concept can be applied to cryptography as well. So, letâs say you want to send a private document to a friend, but you donât want a third party (ppl with malicious intent, for instance) to intercept the paylod and consequently find out the contents of the document. One way to prevent this is to use a complicated scheme/algorithm to obfuscate the original contents of the documentâessentially turning the document into random gibberishâand then send that seemingly gibberish content to your friend. But then, you might ask, âif the contents are gibberish, then how would my friend be able to see the original document?â This is where the key comes in. The algorithm generates the âgibberishâ content based on a key (basically a string of characters) thereby obfuscating the document. And if the recipient knows the same key, they can transform the gibberish content back into the original document. Even if an attacker steals the document in transition, all they will see is gibberish (because they donât have access to the encryption key and are therefore unable to generate the original content). The parallel between an encryption key and a physical key should be fairly clear here. Without the encryption key, nobody can unlock the actual message (provided that the encryption algorithm used is strong enough); without a physical key, nobody can open a lock (provided that the lock is strong enough to withstand physical blows or flamethrowers).
The form of encryption described above is called symmetric encryption since both the sender and recipient use the same key (the keys used on each end of the communication are symmetrical). There is another form of encryption called asymmetric encryption. In asymmetric encryption, different keys are used for the encryption and decryption process (hence asymmetric). You encrypt with one key to generate gibberish, then the recipient will decrypt (unlock) the gibberish with a different key. As with most of the stuff in cryptography, thereâs some very clever mathematics involved, so I wonât go into much detail here. Essentially, the sender owns a pair of keys, one public and another one private. These keys have an interesting property: a message encrypted using one of the pair can only be decrypted with the other one. For example, if you encrypt a message with the public key, only the private key can be used to decrypt the encrypted message (ciphertext), and vice versa. In a sense, these two keys are like counterparts of each other. Again, the reason these keys have this property is due to the very clever mathematics involved in the generation of these key pairs (on Linux, you can generate such a key pair using the gpg command).
The public key is shared publicly, whereas the private key is (yeah, youâve guessed it) meant to be kept a secret. If you want to send a confidential document to a friend, you can, for instance, encrypt the document with your friendâs public key to generate gibberish. That way, only your friend can decode the gibberish content because only his private key can transform the gibberish back into the original content (assuming that your friendâs private key is known only to him). Another use case is when you want to authenticate a document (e.g: to prove to your friend that the document indeed came from you and not from someone else). In this case, you can encrypt the document with your own private key to generate gibberish (please note that this is for illustration purpose only and is not how itâs done in reality; in reality, you would compute a hash of the document first and then encrypt that hash with your private key to generate the signature). Your friend can then regenerate the original content using your public key, which he has access to. If the use of your public key successfully decrypts the message, then your friend can rest assured that the document indeed came from you since the decryption process can only be successful if the message was encrypted with your private key, which you alone possess.
That would depend on whether you actually store any private keys on your system. For example, if you store your passwords, your private keys, github personal access tokens in a regular unencrypted file on your filesystem, I would consider getting rid of them even without this xz backdoor.
5 Likes
I guess it doesnât hurt to get rid of the cached versions of the corrupted xz package tooâŚ
sudo paccache xz -rk1
@Matty
What a perfect welcome to the EndeavorOS community 
âŚso, well, welcome @Matty !
Stay confident that, unlike on other OSâs, at least threats on Linux are spotted eventually. (here itâs a âbugâ not a feature 
)
2 Likes
Crucially, even if it did, liblzma itself is not compromised on Arch; it is the same before and after update (due to the script targeting DEB and RPM exclusively): https://www.openwall.com/lists/oss-security/2024/03/29/20 , as mentioned before.
1 Like
If I understand correctly, when I did my initial set up, it will automatically delete the cache based on what I chose right?
If you did install endeavourOS, it installed a version of xz (potentially the corrupted one).
If you then did a system update (you did right?), it (pacman) replaced xz with the âgoodâ patched version (you can always check with $ yay -Qi xz).
But pacman keeps previous versions of installed (or uninstalled) packages in a cache folder (which is good if you need to downgrade for whatever reason).
I was just thinking that in this case it would be nice to get rid of those previous versions of xz (then making it impossible to revert to them).
Thatâs what sudo paccache xz -rk1 does, ereasing all cached xz versions but the very last one (should be 5.6.1-2 here).
4 Likes
Awesome, I checked the version last night and was on 5.6.1-2, Iâll go ahead and clear the cache for it. Thanks for the assistance!
1 Like
As a general maintenance process you can âautomateâ the cleaning of pacman cache (and the number of packages versions in it) with a timer or a hook.
You can refer to this section of the wiki.
Cheers !
2 Likes
Just business as usual for that zonderful distro 
, nothing they would worry too much about.
1 Like
I donât know, I just did a system update today, and I noticed I do have the xz package. (Iâm using EndeavourOS)
obviously itâs something else thatâs using it, not sshd, but still. Having it on oneâs system at all still leaves them vulnerable, no?
Everyone has it, itâs required by base, check out output of:
pacman -Qi xz
⌠oh I see.
1 Like
I wonder how many other sleeper maintainers still exist out there, that already reached the âtrustedâ status just waiting and bidding their time.
Slightly proving the point of the âHypocrite Commitsâ experiment done by the researchers from University of Minnesota. Yes those guys were kinda being asshole about it and rightfully banned, but the experiment itself do raise a good point about the âtrusted maintainerâ being bad actors that weaved their way from the start.
Obviously they wouldnât get away doing this on literally the Linux kernel itself or any major packages that have hundreds of eyeballs on them. But even someone who arenât well-versed in programming like me knows that we donât have enough experienced volunteers to maintain and keep an eye on every single changes that comes to every single smaller important packages like this one.
3 Likes