Abusing Ubuntu 24.04 features for root privilege escalation
1–10 of 83 posts
Re: Abusing Ubuntu 24.04 features for root privilege escalation
#2I 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.
Re: Abusing Ubuntu 24.04 features for root privilege escalation
#3That 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.
Re: Abusing Ubuntu 24.04 features for root privilege escalation
#4Linux 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.
Re: Abusing Ubuntu 24.04 features for root privilege escalation
#5Linux 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.
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.
Re: Abusing Ubuntu 24.04 features for root privilege escalation
#6Linux 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.
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 se…
They can execute anything they like as root... by entering their password.
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.
Re: Abusing Ubuntu 24.04 features for root privilege escalation
#7Earlier quoted context omitted.
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 se…
They can execute anything they like as root... by entering their password. 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.
Using print server vulnerabilities to gain local privilege escalation is reminiscent of Windows 95. The year of "Linux on the Desktop," I guess.
Re: Abusing Ubuntu 24.04 features for root privilege escalation
#8Linux 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.
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.
Re: Abusing Ubuntu 24.04 features for root privilege escalation
#9Earlier quoted context omitted.
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 se…
They can execute anything they like as root... by entering their password. 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.
> They can execute anything they like as root... by entering their password.
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.
Re: Abusing Ubuntu 24.04 features for root privilege escalation
#10Linux 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.
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…
It became crystal clear that cups is a can of worms, and it would be prudent to completely replace it with with a new solution built from the ground up, ideally using modern tools and standards.