Abusing Ubuntu 24.04 features for root privilege escalation

[samlinnfer]

24.04 also ships with a footgun that keeps PasswordAuthentication enabled even if you edit /etc/ssh/sshd_config. It adds a /etc/ssh/sshd_config.d/50-cloud-init.conf that force overrides any PasswordAuthentication settings you have configured in /etc/ssh/sshd_config.

See here: https://news.ycombinator.com/item?id=42133181

[HumanOstrich]

A better practice is to use the `.d/` convention as intended - so you can have overrides and customizations without having to edit the OS-managed /etc/ssh/sshd_config file and fight it if an OS upgrade changes it.

Edit: It's not really a mistake on Ubuntu's part, and is common in other distros for overriding upstream defaults[1].

[1]: https://askubuntu.com/a/1516347

[homebrewer]

The proposed solution is bad, the file will be restored by the package manager at some point. Always prefix your override files with '99-' or 'zz-', this would have prevented the problem.

[SoftTalker]

I don't have /etc/ssh/sshd_config.d/50-cloud-init.conf on my ubuntu 24.04 machines. What creates it? Is it a clean-install vs. upgrade difference perhaps?

[d0mine]

It is Ubuntu issue, it is cloud-init issue. You can get the same result on other distros provisioned by cloud-init.

[MortyWaves]

Now I definitely feel glad that I decided on moving back to Debian for servers.

[charliebwrites]

Is this true for Ubuntu Server 24 as well?

Was thinking of upgrading but not if I can’t configure SSH to be key only

[yrro]

Am I crazy or have people lost the ability to read documentation?

[xarope]

omg I just disabled this on a major server that was just upgraded to 24.04.

Had to check my other VMs. Luckily most of them are debian or 22.04 (for now).

[BonusPlay]

Linux Local Privilege Escalation, but the attacker has to be in sudo group in the first place.

Great read, but this feels like academic research. Technically correct, but impractical at best.

[nneonneo]

To be precise: you don't need to be in the sudo group, but in the lpadmin group. I'm not familiar with how Ubuntu groups are set up, but I guess it's likely that lpadmin is only granted to administrators by default.

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.

[rlpb]

To expand on this: if the user is in the sudo group, they have explicit permission to execute anything they like as root. If someone wants a user to not be able to do this, they don't put that user in the sudo group. As far as I can tell from the write-up, if you remove a user from the sudo group because you don't want them to have that privilege then this "exploit" won't work.

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.

[dTal]

If that is your attitude, why bother with the sudo group at all? Just run as root.

(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.)

[fred_is_fred]

That was a great read. The way the author builds the exploit, brick by brick, is well done and not all all obvious or clear. Each step by itself is somewhat concerning but there's no Eureka! moment until very late.

[schoen]

I wonder if there's a tool to create dependency graphs for these dbus and polkit interactions, ideally to better audit those that seem to cross interesting trust boundaries.

[trod1234]

Not surprising, Ubuntu has suffered a wide array of issues going all the way back to their releases following 18.04 LTS.

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.

[sheerun]

The only feedback I get when installing d-spy is "Uses System Services", and "Uses Session Services", which means nothing to me as a user, and yet it allows program to enumerate all programs I use and as it turns out even hack my computer. Other platforms solved this with something like "developer mode", iOS, Android, Meta, etc. I shouldn't be able to install this app without confirming developer-mode-only permissions. As for this particular app it is offline, yes, but dbus allows for cross-app communication, so no more

[nneonneo]

You’re running desktop Linux - your whole system is permanently in “developer mode”. That’s kind of the point? Windows and macOS don’t have “developer mode” either, at least not to the extent seen in the mobile OSes.

They’re very different models of computing.

[sylware]

It is time to stop that: there is no "security", this is a fantasy which does not exist. Nowadays, anybody saying otherwise is trying to sell you something.

The only real security is to protect basic users from themselves, namely breaking their systems. That's it. (rm -Rf /)