There are more details and a list of affected packages being compiled in a thread here https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/FGXPCB3ZVCJIV7FX323SBAX2JHYB7ZS4/

Changes contributor email, adds npm to the PKGBUILD dependencies and installs malicious packages that take various keys and passwords (Browser logins, SSH, etc)

This persists on the machine with a systemd service and eventually pretends to be a kernel thread

The source:

https://cybernews.com/security/xubuntu-site-compromise-hackers-peddle-malware/

BEWARE

Since yesterday Arch Linux maintainers have been working to reset/delete all of the malicious content and banning affected accounts. Over 400 packages are believed impacted by this latest malware campaign for Arch Linux's AUR. Again, to be completely clear, this just is affecting AUR packages and not the official Arch Linux packages.

https://www.phoronix.com/news/Ubuntu-26.10-Lighter-GRUB

“Ubuntu developers at Canonical are looking to strip the signed GRUB bootloader features to the bare minimum for the Ubuntu 26.10 release later this year. Dropping support for XFS, ZFS, Btrfs, LVM, md-raid (except RAID1), LUKS-encrypted disks, and other features is being looked at in the name of security.

Due to various parsers and other features being a "constant source of security issues" with the GRUB bootloader, Ubuntu 26.10 is likely to remove a lot of features from the signed GRUB builds necessary for Secure Boot support. This would include removing GRUB's support for the Btrfs, XFS, and ZFS file-systems, among others. It would also remove support for the Logical Volume Manager (LVM), remove md-raid except RAID1, and also remove support for LUKS-encrypted disks.

These file-systems and features like LVM and LUKS-encrypted disks would still be supported by Ubuntu itself but not the default signed GRUB bootloader. Ripping out all of these GRUB features would basically mandate that most Ubuntu 26.10+ installations are done with the /boot partition being done on a raw EXT4 partition. Thus no more encrypted boot partition and having to rely on an EXT4 boot partition even if you are a diehard Btrfs / XFS / OpenZFS fan. Or you could opt for the non-signed GRUB bootloader that would be more full-featured albeit lacking Secure Boot and security compliance.

How on earth this got past stupidity control is beyond me.

Ubuntu, are you okay?

Unbelievable.

https://discourse.ubuntu.com/t/streamlining-secure-boot-for-26-10/79069

Just be aware, Xubuntu.org got hacked and their download button tries to download “Xubuntu-Safe-Download.zip”, that seems to include a fake TOS and an EXE, and Virustotal confirms malware (a Trojan) inside of it. Seems someone’s trying to get noobs from Windows that could be interested in Linux (more so now because the Win10 EOL)

Hope the people at the Xubuntu project and Ubuntu/Canonical can take fast actions, but this seems has been up for 6h now, going by the first people that noticed. Having this vulnerability up for 6h shouldn’t be OK.

UPDATE: After 12h, the Xubuntu website deleted this and now has temporarely closed the redirection from the "Download" buttons.

About the malware, it seems to be a Crypto Clipper. When you launch it and click "Generate Download Link", it saves "elzvcf.exe" to AppData Roaming, and configures a registry key to get persistance and startup run.

From there, I could especulate it's a simple script that tries to hijack the clipboard, so when it detects a crypto address, it will exchange it for a different one when you paste it, hoping the hacker gets whatever you try to send.

Very basic, even wroted with AI as it seems, but working. Thanks everybody

I've seen people elevating their tmux shells for convenient root access many times, often leaving the sessions running in the background for a long time.

Doing this makes it very trivial to escalate permissions for anybody that gets a shell to your box with your user.

Instead, you should run sudo tmux in another session, then do your thing there. This limits access to the tmux service for the root user only, which prevents the privilege escalation path.

Scenario: You want to copy some configuration files into /etc. Your distro is likely using Nautilus (GNOME), Nemo (Cinnamon), or Dolphin (KDE) as its graphical file manager. But when you try to paste the file, it tells you "permission denied". You grumble and open a terminal to do the copying. Your disappointment is immeasurable and your workflow is ruined.

Edit: I would like to point out that a similar problem occurs when attempting to copy files to another user's folder. This happens occasionally in multi-user systems and it is often faster to select several files with unrelated names in a GUI environment than type them out by hand. Of course, in this case, it's probably undesirable to copy as root, but copying nonetheless requires root, or knowing the other user's password (a separate problem in itself)

It is obviously possible for a non-root process to ask the user to provide a password before doing a privileged thing (or at least do such a good job emulating that behaviour that the user doesn't notice). GNOME Settings has an "unlock" button on the user accounts management page that must be pressed before adding and editing other user accounts. When the button is pressed, the system prompts the user to enter their password. Similarly, GNOME Software Centre can prompt the user for their password before installing packages.

Compare: Windows (loud booing in the background) asks the user in a pop-up window whether they want to do something as an administrator before copying files to a restricted location, like C:\Program Files.

It's 2022. Why hasn't Linux figured this out yet, and adopted it as a standard feature in every distro? Is there a security problem with it I don't yet know of?

Target audience: If you rely on TPM registers 0-7,9,12-14 and expect a specific value from them, for example, LUKS unlock.

Why it matters: Under normal circumstances, a TPM PCR-0 can go an entire lifetime without ever changing. It measures the built-in UEFI, and only a firmware update can potentially change it. Something like PCR-7 can only change if someone messed up with the secure boot policy and keys.

When you do none of these things and suddenly most PCRs change after a reboot, you might get worried. Apart from the subject of this post, this behaviour is usually seen in a rootkit-level infection.

What you should know:

• SystemD, starting from version 261, has introduced a new set of services related to TPM management.
• The one that concerns us is called systemd-pcrosseparator.service ("TPM PCR OS Separator")
• What it does: After the firmware finishes its measurements, this service stamps them, so to speak. It registers a new string "os-separator" on top of whatever recorded hashes are in the TPM in the PCRs 0-7,9,12-14. More details in the service's man page here, or here, or here.
• If you rely on these registers having an expected value, they no longer do, and you will need to re-enrol them.
• Depending on how your system boots and who creates the initial ramdisk, you will not immediately see a change just because SystemD got updated to 261. In fact, 261 has been available on rolling distros for a while now. It's up to the ram disk generator to incorporate these changes.
• In the case of Arch (What I use, btw), mkinitcpio adopted these changes in version 42. The official changelog explicitly states that.
• Different distros will have different timelines, but it seems they'll be heading in the same direction, so do look out for this change and be prepared so you don't panic.

How to prepare:

• Before the new versions hit you, it would be a good idea to save the values in your current registers into a file. I do this after every important register change, such as when I change the shim version, secure boot keys, or similar: sudo tpm2_pcrread > ~/tpm/tpmXX (XX an incrementing number)
• Of more importance, saving the TPM event log, which can show you how these values were obtained: sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements > ~/tpm/event.log
• When the updates hit and your reboot does not automatically unlock your LUKS, or whatever software you rely on TPM for fails the security check, save a new copy of the registers to see what changed and verify it's really the new OS Separator. Then save a new event log and verify that the values in the old and new event log are practically the same, because OS Separator tampering is not recorded in this log.
• If the event log shows no discrepancy, you can be sure it's not a rootkit, just SystemD stuff, and you can re-enrol the new PCR values.

Thanks for reading thus far. It took me a few hours of chasing leads yesterday till I figured out what was happening. I wish Arch would have dedicated a front-page post to something this important.

Another Linux vulnerability in the same category as Dirty Frag has been found! Another eight of these more I guess? In any case the fatigue is coming up for me. Things are getting crazy!

"It abuses a logic bug in the Linux XFRM ESP-in-TCP subsystem to achieve arbitrary byte writes into the kernel page cache of read-only files, without requiring any race condition."

Let's imagine a journalist facing a nation-state level adversary such as an oppressive government with a sophisticated tailored access program.

Further, let's imagine a modern laptop containing the journalist's sources. Modern mainstream Linux distro, using the default FDE settings.
Assume: x86_64, no rubber-hose cryptanalysis (but physical access, obviously), no cold boot attacks (seized in shut down state), 20+ character truly random password, competent OPSEC, all relevant supported consumer grade technologies in use (TPM, secure boot).

Would such a system have any meaningful hope in resisting sophisticated cryptanalysis? If not, how would it be compromised, most likely?

EDIT: Once again, this is a magical thought experiment land where rubber hoses, lead pipes, and bricks do not exist and cannot be used to rearrange teeth and bones.
I understand that beating the password out of the journalist is the most practical way of doing this, but this question is about technical capabilities of Linux, not about medieval torture methods.

There seems to be a "Type Confusion in V8" (V8 being the JS engine), and Google is urgently advising users to upgrade to v99.0.4844.84 (or a later version) because of its security implications.

CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1096

Context:

- I set up a new raspberry pi and while setting up, i stumpled upon the question of security on a shared device

- During research, I noticed that even when you set a password, your file repository can be read, including the stored keys of your browser

- To prevent that, you would need to encrypt your disk (that's different from just using a password for your user)

---

So, how do you do it? Do you encrypt your disk? Do you enter the password twice then on boot or do did you configure auto login after decryption?

I might set up my Fedora + Rasp Pi new with it enabled, I assume it can be easily set up during installation?

How do you handle it?