Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Abusing Ubuntu 24.04 features for root privilege escalation

snyk.io

Post reply on HN
Print view View original

51–60 of 83 posts

Re: Abusing Ubuntu 24.04 features for root privilege escalation

#51

Post by [deleted] »

DaSHacka wrote: post #50
HumanOstrich wrote: post #48

Earlier quoted context omitted.

Err, why? Nothing is actually broken with Ubuntu 24.04. The issue GP is describing is just a lack of understanding of how config files have worked on Linux for decades. 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.

Any sufficiently poorly constructed system is indistinguishable from a legitimate vulnerability. 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 expec…

[deleted]

Re: Abusing Ubuntu 24.04 features for root privilege escalation

#52

Post by HumanOstrich »

DaSHacka wrote: post #50
HumanOstrich wrote: post #48

Earlier quoted context omitted.

Err, why? Nothing is actually broken with Ubuntu 24.04. The issue GP is describing is just a lack of understanding of how config files have worked on Linux for decades. 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.

Any sufficiently poorly constructed system is indistinguishable from a legitimate vulnerability. 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 expec…

They likely chose the option to enable password-based SSH authentication during installation [1], or it's a cloud service that provisions servers with a password.

I've been looking for info about whether it's force-enabled with a vanilla install where the user doesn't actually choose for it to be enabled. I'm happy to be educated here.

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

Re: Abusing Ubuntu 24.04 features for root privilege escalation

#53

Post by SoftTalker »

samlinnfer wrote: post #15

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

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?

Re: Abusing Ubuntu 24.04 features for root privilege escalation

#54

Post by HumanOstrich »

SoftTalker wrote: post #53
samlinnfer wrote: post #15

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

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?

Unfortunately, one possibility is the user chose "enable SSH password authentication" during the install [1]. Or it's a cloud instance from a provider that provisions instances with a password.

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

Re: Abusing Ubuntu 24.04 features for root privilege escalation

#55

Post by SoftTalker »

nneonneo wrote: post #28
dTal wrote: post #18

Earlier quoted context omitted.

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

Honestly, sudo’s value is really sanity, not security. 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. Realistically,…

Sudo is so commonly used especially on developer machines that I think it is used reflexively without any thought at at all.

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.

Re: Abusing Ubuntu 24.04 features for root privilege escalation

#56

Post by Brian_K_White »

HumanOstrich wrote: post #48
MortyWaves wrote: post #21

Earlier quoted context omitted.

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

Err, why? Nothing is actually broken with Ubuntu 24.04. The issue GP is describing is just a lack of understanding of how config files have worked on Linux for decades. 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.

Actually ubuntu and/or some cloud integrator is violating principle of least suprise, which predates by even more decades and applies everywhere not just in a computer operating system.

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.

Re: Abusing Ubuntu 24.04 features for root privilege escalation

#57

Post by vbezhenar »

SoftTalker wrote: post #53
samlinnfer wrote: post #15

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

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?

This file is created when the server is provisioned with cloud-init. For example when you use https://cloud-images.ubuntu.com/ as a template image to create your VM. For these cases you would need to supply cloud-init config via separate means (openstack user-data or just secondary mounted ISO) and cloud-init would perform post-install tasks like configuring users, passwords, ssh keys, etc. If you just install your machine from ISO, cloud-init is not used.

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.

Re: Abusing Ubuntu 24.04 features for root privilege escalation

#58

Post by vbezhenar »

MortyWaves wrote: post #21
samlinnfer wrote: post #15

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

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

It works identically for debian. Just today I configured debian server with cloud-init and it created absolutely the same file.

Re: Abusing Ubuntu 24.04 features for root privilege escalation

#59

Post by HumanOstrich »

Brian_K_White wrote: post #56
HumanOstrich wrote: post #48

Earlier quoted context omitted.

Err, why? Nothing is actually broken with Ubuntu 24.04. The issue GP is describing is just a lack of understanding of how config files have worked on Linux for decades. 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.

Actually ubuntu and/or some cloud integrator is violating principle of least suprise, which predates by even more decades and applies everywhere not just in a computer operating system. 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…

That's just not how it works, and it never has. One of the main purposes of the .d files is to avoid modifying the distro's sshd_config file, so you don't have to resolve conflicts during an OS upgrade. Commenting your overrides in the sshd_config? That's backwards.

Downstream distros sometimes want to override the default settings. That's what .d is for. It doesn't violate the dogma "principle of least surprise", especially if you run `man sshd_config` and learn the first thing about sshd's config files.

Re: Abusing Ubuntu 24.04 features for root privilege escalation

#60

Post by vbezhenar »

dTal wrote: post #18
BonusPlay wrote: post #4

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.

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

It's security cargo cult.

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

Post reply on HN