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.
And if you downloaded and installed the authentic Debian 12 image from debian.org, you don't get it either. Must be a Ubuntu thingy.
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.
Having /etc/ssh/sshd_config not do what it appears to do is inexcusable, however that comes about.
Even if the fix is no more than structuring the file a little differently so there are parts both before and after the .d loading, and comments that say what overrides what, and all the actual config files and default behavior are still the same.
You shouldn't need to edit an undocumented file that's force enabling an insecure authentication method in the first place.
"You're using it wrong" doesn't change the fact that the defaults are poor and likely to ultimately cause more devices to be improperly configured than if it was left as sysadmins and end-users expect.
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.
thing like cups should be easy to sandbox, especially if we allow dbus like APIs as a means to cross sandbox boundaries (i.e. RPC mechanism).
and by sandbox, I dont mean simply use apparmor type rules (though that can work), but a cups that lives within its own file system and nothing else is even visible.
i.e. programs will always be buggy, even if we get rid of all language oriented bugs, there will still be logic bugs that will result in security holes. We just need to make it easy to isolate programs (and services) into their own sandboxes while retaining the ability for them to interact (as otherwise, lose much of the value of modern systems).
In practice, I would argue, a lot of modern systems do this already (ala ios/android). The apps run sandboxed and only have restricted abilities to interact with each other.
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.
If it has control of your user account, then it can just arrange to wrap your shell prompt and wait for you to sudo something else. The sudo password prompt in its default arrangement doesn't really provide much security there and isn't expected to.
(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.
It should not be, but that's a different issue. It amazes me the amount of open-source projects that want to be installed with "sudo" when there is no reason they should not be able to be built and used entirely from within the developer's home directory.
I know more than one person who starts a shell session with "sudo -i" and then just works as root because typing "sudo" all the time is an annoyance.
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 /)