New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
New sudo vulnerability disclosed
CloudHopper
Member
in News
A new bug in the "sudo" command allows arbitrary Local Privilege Escalation. As I understand it, it's very easy to exploit but the attacker would still need access to the box as an unprivileged user.
The user doesn't need to be in the sudoers file, they just need to exist on a system with sudo installed, so Shared Hosting might be an issue if not patched:
https://thehackernews.com/2025/07/critical-sudo-vulnerabilities-let-local.html?m=1
Comments
Thank you for reposting.
That's why I usually use
doas.Much smaller codebase, less unnecessary functionalities and thus smaller attack surface.
Probably more of a reason to treat sharing SSH access to someone as effectively giving them root. Who knows what other vulnerabilities remain unpatched. Iām not saying sudo is bad, but when setting things up, assume that every user can gain sudo access.
Ooopsie!
this article is quite terrible. here's the actual advisory from
sudo: https://www.sudo.ws/security/advisories/chroot_bug/tl;dr CVE-2025-32462 is root escalation but requires existing root to have fucked up the sudo config using a sudo feature I've never even heard of before, some badly thought-out chroot features.
everyone should have already been upgraded before this lame tier of security blogspam went out - if you don't have
unattended-upgradesinstalled on all your debian/ubuntu servers already, go fix that instead of wasting time on this thread or that article.so to add a FAQ:
q: should I be worried about this?
a: no, if you're asking, you didn't enable this feature. you already installed
unattended-upgradesand it already upgraded sudo so you're not even theoretically vulnerable now.q: should I stop using sudo?
a: yes in the medium term, setuid privilege escalation was a bad idea anyway, use
run0or, if you can't,doasin the meantime.q: should I let random people ssh in to my servers?
a: no
q: but I'm a mass web hosting provider and I'm not very good at being a sysadmin
a: I'm sorry for your life choices
Debian already fixed it on June 30
https://lists.debian.org/debian-security-announce/2025/msg00118.html
okay i hear you but what if i want to show them this really cool thing?
But it's not really about ssh vs. no ssh - it's about letting people run arbitrary binaries on the server. And if you are a web hoster, good luck telling them they can only host static pages from now on.
It's a 9.3, I already explained it's a Local Privilege Escalation, and the blog you link explains that it's a sudo bug that's been reverted.
The use of -R is just how you exploit the bug*
*Despite it being explicit and easily available, I'm still trying to avoid explaining the mechanism in detail.
I'll also add that unattended-upgrades is commonly disabled in sensitive production systems to avoid unexpected changes breaking things. In fact, "proper" SysAdmins are usually bound up in change-request processes to get approval to fix it, (after proving it's safe in Dev and Staging and all the other auditing etc)
yes, it's true that it is just a general privesc vulnerability, and can be exploited by people running code on your machine in other ways...however! if you're letting people run random code on your machine as a web host, they should be contained, e.g. in a
chroot(not using this sudo feature obviously!) that doesn't havesetuidbinaries in it.allowing people to run random code is a hugely complicated topic and requires great care, but in that case you shouldn't be getting security advice from forums.
as you were probably also thinking, this is also a risk in lots of other cases, e.g. if I'm running my own Wordpress or whatever and it has some code exec bug, then that plus the sudo bug is remote root. we're lucky in this case that it is a non-default config bug, but I think people should put thought in to sandboxing their own services better, e.g. running Wordpress in rootless podman with very little aside from php.
I believe this activity on LET is known as "Shared-Hosting" and I posted it here because it's one of those time-critical issues that's easy to solve and easy to exploit so it seemed relevant
Mate, seriously. I'm chilling in a bar and my servers aren't patched yet. But only I have access to them so I have other things to worry about on Friday night.
However, I really need to reinforce this for other readers....
THIS IS A DEFAULT CONFIG BUG
I tested it for my company before going out for beers, without updating my own servers because an LPE in my world is a Medium at best.
you are correct (https://www.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot):
specifically for versions 1.9.14 to 1.9.17.
the sudo advisory (https://www.sudo.ws/security/advisories/chroot_bug/) really should have been clearer.
on the plus side, debian stable isn't vulnerable: https://packages.debian.org/bookworm/sudo
thanks for correcting me!
wish I could edit my previous post!
Thanks for sharing!
Gotz to patch tha sudo
It's not about you. But thanks for your participation š
Debian rules...but you've still got to update it, assuming you dont have an automation setup for it š
Today was sudo on my debian update.