[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7d8815b7-a417-4407-87a3-fb0dc7c4f81f@gmail.com>
Date: Fri, 6 Jun 2025 15:40:20 +0200
From: Attila Szasz <szasza.contact@...il.com>
To: Solar Designer <solar@...nwall.com>, oss-security@...ts.openwall.com
Cc: Muhammed Hüsam Alzeyyat <hussamalzeyyat@...il.com>
Subject: Re: Linux kernel: HFS+ filesystem implementation
issues, exposure in distros
> 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.
Also, many customers ofhttps://ubuntu.com/pro, I think.
Incidentally, I don't know how active user sessions in polkit and the
state of being a sudoer vs non-sudoer works when you hook up workstations
to AD, but it might be interesting.
On 6/2/25 22:59, Solar Designer wrote:
[..]
> If nothing else, this can be used to bypass UEFI Secure Boot.
Could be. Also, I know that Debian wanted to disable hfs/hfsplus
altogether in kernel config, but it was pointed out that
powerpc and ppc64 still needs that - I guess for booting properly.
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1422
https://github.com/AOSC-Tracking/debian-kernel-team-linux/commit/9b5d19e4bb14e65ff3295e7af394f4048a3bfba0
https://salsa.debian.org/kernel-team/linux/-/commit/d522d84d1b39689b31030eda65b33b29bada5a9a
> Do I correctly read "(any<=5.6)" as indicating that the filesystem
> corruption bug has been fixed for a long time now?
Yeah, so there was a fix for something that was reported as a
stability problem*, and that, combined with the slab OOB write
could result in the vector that I'm discussing there. The one
without the need to mount a corrupted state.
Incidentally, this also means that if the kernel had actually refused
to fix the issue — which they did for about 5–6 months, only upstreaming
the fix on the same day the CVE was rejected — then the stable 5.4
release would have been affected by that vector
even though the whole thing was kinda dismissed as a non-CVE.
I'll let the reader judge whether this is the right way to
do conservative defense-in-depth or not.
* this was actually the commit that piqued my interest,
because it indicated that something really fishy was going on
about manipulating the B-tree's on disk.
I talked about this for a smaller group of audience, but
I ran into this whole mess through an IoT security evaluation
of sorts by noticing that the company Tuxera used to sell
their HFS+ 'on steroids' solution for Asus, Linksys and a bunch
of manufacturers where the kernel module was essentially just the
upstream driver. Even from the decompiled snippets it was clear that
that driver was somewhat unstable.
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.
