It seems I have overlooked this thread, and want to chime in.
On 2025-06-06 09:40, Attila Szasz wrote:
OTOH, is there other significant security impact? As I understood, on
Ubuntu a privileged logged in user could use this bug to obtain root.
However, is that user perhaps privileged enough to also sudo to root by
default? So is this only a bypass of the need to re-enter the user's
password for sudo? That sudo from user to root is only a nominal
protection mechanism anyway, more against inadvertent mistakes than
against malicious attacks.
I didn't make this explicit in the video, but this works when
running as a non-sudoer user, and also on Ubuntu Server. I think
Canonical Product Security might have better estimates on this, but
I'm guessing many of the corporate, gov, academic, HPC cluster, etc
use cases are impacted practically in such a setting.
This isn't supposed to work for non-privileged users, and not on servers. We
allow mounting usb drives for admin users sitting at the console by shipping a
package called "policykit-desktop-privileges" which contains the following
polkit rule:
[Mounting, checking, etc. of internal drives]
Identity=unix-group:admin;unix-group:sudo
Action=org.freedesktop.udisks2.filesystem-mount-system;org.freedesktop.udisks2.e
ncrypted-unlock-system;org.freedesktop.udisks2.filesystem-fstab;
ResultActive=yes
Regular unprivileged users should not be in the admin group or the sudo group,
and as such should not be able to mount usb drives. Servers shouldn't have that
package installed either.
Now, that being said, I don't think asking an admin for their password is enough
justification to allow running arbitrary code. An admin wouldn't expect
inserting a USB drive would allow code execution whether or not they had to
enter their password.
Marc.
