[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <837bfdec-33e5-43d1-9340-9b1b79218c85@gmail.com>
Date: Wed, 11 Jun 2025 19:10:24 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux kernel: HFS+ filesystem implementation
issues, exposure in distros
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)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
