Miniflux to get all my feeds which I can analyze manually throughout the day and send selected snippets to Wallabag for later reading either during lunch or at night using KOReader client in KPW4.
Some no-name came and without any problems asked to become a maintainer in a project used in almost any distro, took it over, put a backdoor in there and no one had any questions? In this case, everything turned out thanks to pure chance. Noname screwed up his backdoor, which attracted the attention of a guy from Microsoft, and out of boredom, he dug up what was what. And if I hadn’t messed up, or that guy from Microsoft decided to go drink beer instead of poking around in the xz code, then no one would have discovered anything.
It’s scary to imagine how many of these nonames are sitting in all these thousands of open source projects, waiting in the wings to roll out a malicious patch.
Since the actual operation of the liblzma SSH backdoor payload is still unknown, there’s a protocol for securing your impacted systems:
• Consider all data, including key material and secrets on the impacted system as compromised. Expand the impact to other systems, as needed (for example: if a local SSH key is used to access a remote system then the remote system must be considered impacted as well, within the scope the key provides).
• Wipe the impacted host and reinstall it from scratch. Use known good install that does not contain the malicious payload. Generate new keys and passwords. Do not reuse any from the impacted systems.
• Restore configuration and data from backups, but from before the time the malicious liblzma package was installed. However, be careful not to allow potentially leaked credentials or keys to have access to the newly installed system (for example via $HOME/.ssh/authorized_keys).
This handles the systems themselves. Unfortunately any passwords and other credentials stored, accessed or processed with the impacted systems must be considered compromised as well. Change passwords on web sites and other services as needed. Consider the fact that the attacker may have accessed the services and added ways to restore access via for example email address or phone number in their control. Check all information stored on the services for correctness.
This is a lot of work, certainly much more than just upgrading the liblzma package. This is the price you have to pay to stay safe. Just upgrading your liblzma package and hoping for the best is always an option, too. It’s up to you to decide if this is a risk worth taking.
This recovery protocol might change somewhat once the actual operation of the payload is figured out. There might be situations where the impact could be more limited.
As an example: If it turns out that the payload is fully contained and only allows unauthorized remote access via the tampered sshd, and the host is not directly accessible from the internet (the SSH port is not open to internet) this would mean that it might be possible to clean up the system locally without full reinstall.
However, do note that the information stored on the system might have still been leaked to outside world. For example leaked ssh keys without a passphrase could still afford the attacker access to remote systems.
This is a long con, and honestly the only people at fault are the bad actors themselves. Assuming Jia Tan’s GitHub identity and pgp key weren’t compromised by someone else, this backdoor appears to be the culmination of three years of work.
I will laugh out loud if the “fixed” binary contains a second backdoor, but one of better quality.
It’s reminiscent of a poorly hidden small joint, which is naturally found, and then bargaining, apologizing and making amends begin.
Although now it is generally not clear where the code is more proven.
Try to build Coreboot on Lenovo G505S using the restore_agesa.sh script in conjunction with the csb_patcher script, which applies a group of unofficial patches for AMD platforms
Lenovo G505S 16gb RAM - no (the A10-5750M processor has neither Intel ME nor AMD PSP), software probes - too, if instead of the closed UEFI from the manufacturer you install the open source BIOS coreboot+SeaBIOS: it will contain only a few small closed binaries , they were all dismantled and no backdoors were found. Someone made a script in which by rolling back 1% of the last commits (made after deleting the G505S) you can return AMD boards to coreboot - https://review.coreboot.org/c/coreboot/+/76832. You can install the AR9462 module, whose ath9k family WiFi is 100% open source.
I’m currently using KeePassXC. The setup that I created below gives me 3-backups of my passwords, but it’s a bit to manage.
Computer
On my computer, I have my keepassxc database and key file stored in a veracrypt container. Next to my computer, I have a piece of paper that has the password for my keepassxc database and the password for my veracrypt container.
KeePassXC Export File (text file that contains all of my login information)
I store this file inside of a veracrypt container, on my USB LUKS. Next to my USB LUKS, I have a piece of paper that has the associated veracrypt password.
usb luks -> veracrypt container -> keepassxc export file
paper -> veracrypt pw
Cloud
I store my database in cloud service a.
I store my key file in a veracrypt container, in cloud service b.
On a piece of paper, I have the login information to both of these cloud accounts and the password for the veracrypt container.
4·7 months ago
I also installed Newsboat as an alternative to the web interface https://newsboat.org/releases/2.35/docs/newsboat.html#_miniflux