Hi, Thank you Marco and Tomášor handling this disclosure so well!
I'll add below a little piece of discussion from the distros list, which I think may be helpful to a wider audience. On Thu, Aug 28, 2025 at 04:41:50PM +0200, Tomáš Bžatek wrote: > On Wed, 2025-08-27 at 23:01 +0200, Solar Designer wrote: > > I looked a bit into exposure of this vulnerability for attack: > > > > I checked a few Linux server systems, and I do not see udisks running > > anywhere by default, but simply running: > > > > $ udisksctl monitor > > Monitoring the udisks daemon. Press Ctrl+C to exit. > > 22:49:43.365: The udisks-daemon is running (name-owner :1.49). > > > > as an unprivileged user ssh'ed in remotely gets udisksd started as root > > e.g. on Rocky Linux 9 and on an old Fedora, so it's exposed for attack > > anyway. The user isn't a sudoer and isn't in group wheel. > > UDisks is primarily a D-Bus daemon and set for autoactivation through > its well-known name and there's a D-Bus service policy file for that. > It can be started via an initscript/systemd unit as well, that's up to > distro discretion. > > > The below also works to get udisksd started as root, but requires the > > user to be in group wheel and to re-authenticate: > > > > $ systemctl start udisks2 > > ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ==== > > Authentication is required to start 'udisks2.service'. > > Authenticating as: user > > Password: > > ==== AUTHENTICATION COMPLETE ==== > > > > Trying to actually trigger the bug from the provided Python script (the > > crash one) as a user ssh'ed in remotely to Rocky Linux 9, I get: > > > > gi.repository.GLib.GError: g-io-error-quark: > > GDBus.Error:org.freedesktop.UDisks2.Error.NotAuthorizedCanObtain: Not > > authorized to perform operation (36) > > > > So maybe it's not fully exposed even if the user can start udisksd on > > demand. When I ran the script as root, it crashed udisksd just fine. > > > > What are the permissions commonly required for this? > > Access is guarded through Polkit rules, in this case: Tomáš provided a link to latest revision, but here's one updated to point to the current revision specifically (so that it stays valid): https://github.com/storaged-project/udisks/blob/b495ae587662747b373b5d32c284529e048aebf8/data/org.freedesktop.UDisks2.policy.in#L183-L192 <action id="org.freedesktop.udisks2.loop-setup"> <description>Manage loop devices</description> <message>Authentication is required to set up a loop device</message> <defaults> <allow_any>auth_admin</allow_any> <allow_inactive>auth_admin</allow_inactive> <!-- NOTE: this is not a DoS because we are using /dev/loop-control --> <allow_active>yes</allow_active> </defaults> </action> > So really depends how is your session classified and yes, the attack > surface is slightly lower for non-local seats. However, combine it with > other CVEs, notably CVE-2025-6018, and you have a bigger problem. CVE-2025-6018: LPE from unprivileged to allow_active in *SUSE 15's PAM https://www.openwall.com/lists/oss-security/2025/06/17/4 > > For the potential privilege escalation attack, is the negatively indexed > > fd located within the same heap object or a different one? Would e.g. a > > guard page before the allocation, such as planted by hardened_malloc, > > affect the ability to mount this attack? (We're actually running with > > hardened_malloc in CIQ's RLC-H product.) > > I'm not a security expert and this spans to the glib code > (g_unix_fd_list_get) as well. > > > Would it be good practice to exclude udisks2 from default installs of > > server systems? I tried "rpm -e udisks2" on Rocky Linux 9 and it just > > completed, meaning there were no dependencies on this package (at least > > known to RPM). > > It's not really needed for minimal installs, it's used primarily by > desktop environments and server management consoles like Cockpit. For > RHEL specifically, its inclusion by default AND udisks2.service being > enabled by default is mostly historic relic I guess. Thanks again, Alexander
