Re: Linux kernel: HFS+ filesystem implementation issues, exposure in distros

[Demi Marie Obenour <demiobenour () gmail com>]

On 6/11/25 12:14, Marc Deslauriers wrote:
> 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.

Such code execution is already possible if the drive is vulnerable to BadUSB
unless USB keyboards are blocked.  That said, I think it would be best for
someone (perhaps from Canonical?) who cares about this aspect of security to
become a comaintainer of the relevant kernel code.  It is clear that there
are quite a few people who agree with you, but none of them are currently
upstream filesystem maintainers, and they are the ones who Greg K-H asks when
making decisions as to what is and is not a vulnerability.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature