Edit: It's not really a mistake on Ubuntu's part, and is common in other distros for overriding upstream defaults[1].
I guess that many hosters will use cloud-init for their VPS offerings "under-the-hood". Usually they'll generate password and mail it to you, so obviously ssh password should be allowed for this case.
On top of that, this issue doesn't even "ship with 24.04". GP probably chose to enable password auth in SSH during installation, or they used a cloud provider that provisions instances with passwords and overrides the default.
I thought I fixed it, but apparently not. It is driving me crazy.
Was thinking of upgrading but not if I can’t configure SSH to be key only
This would work: echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/60-password-auth.conf
Had to check my other VMs. Luckily most of them are debian or 22.04 (for now).
Great read, but this feels like academic research. Technically correct, but impractical at best.
That said, I'm guessing people aren't expecting lpadmin to mean a full privilege escalation to root.
There are two bugs here: one in cups, which allows it to chmod anything 777 (doesn't properly check for symlinks, or for the failure of bind), and one in wpa_supplicant, which lets it load arbitrary .so files as root. However, I suspect that even if these bugs are fixed, having access to lpadmin will still be a powerful enough primitive to escalate to root given the rather sizable attack surface of cups.
The bugs found look correct and have security implications, but what is demonstrated is therefore not really "root privilege escalation" since it applies only to users who already have that privilege.
This post shows a way that clever code can execute anything it likes as root without knowing the user's password. That seems pretty significant to me.
(For what it's worth, I think most people would not lose much security from running as root, and the obsession with sudo is so much security theater, for exactly this sort of reason.)
And while lpadmin users can escalate, I’m more interested in escalations from services like web servers or whatever, running as low priv users. I use sudo to allow scripts running as my web server to run specific limited privileged programs as a simple layer of defence.
Use sudo instead of root. Change ssh port. Disable ssh passwords. Use some port knocking schemes or fail2ban. Close all ports with firewall. Some of those requirements might come from some stupid complicance rules, but usually they just come from rumors and lack of clear understanding of threat model. And sometimes they might even slightly reduce security gurantees (like changing ssh port to 10022, there's actually a security reason why only root can bind to <1024 port and by changing it to higher port you lose some tiny protection that unix greybeards invented for you).
I'm not saying that all those measures are useless, in fact I often change ssh port myself. But I'm doing that purely to reduce log spam, not because that's necessary for security. Configuring firewall might be necessary in rare cases when brain-dead software must listen on 0.0.0.0 but must not be available outside. But that's not something given and should be decided in case-by-case basis, rather than applied blindly.
The first time you use certain flavors of sudo, you get a nice little message which reminds you why sudo exists:
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
Because in both cases, you must auditd, and then you understand that sudo adds few values
D-BUS has long been targeted by attackers for the exact reasons the author goes into (its fairly common knowledge in some circles). Not just because of the difference in security contexts but also because of the lack of visibility on these channels with OOB configurations for logging/monitoring.
D-BUS Activation has also been targeted before, many times for its ability to effectively re-parent a process under different pids/names/users, and hiding that process is usually not that hard using a simple mount bind on the associated /proc/pid and mounts directory post exploitation.
With the poisoning of the Ubuntu repository (with fixup scripts to re-enable snap), their security posture became untenable, but has only gotten worse over time.
They’re very different models of computing.
The only real security is to protect basic users from themselves, namely breaking their systems. That's it. (rm -Rf /)