Re: HFS/HFS+ are insecure
Hi Marco, hi,
Marco d'Itri - 21.07.23, 10:55:39 CEST:
> On Jul 21, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > > You are totally correct.
> > > Kernel team, please blacklist HFS/HFS+ for automounting.
> >
> > Isn't this a userland policy decision? udisks will happily trigger a
> > module load for hfsplus if udev has identified it, and I don't think
> > there's a trivial mechanism for the kernel to disable that. I
> > believe
>
> Yes, I was also thinking about this and I believe that you are right.
> The kernel team did this in the past for some uncommon network
> protocols, but they could do it themselves because these modules are
> autoloaded using aliases.
>
> Since I happen to be the kmod maintainer it looks like that solving
> this is on me. :-)
>
> Unless somebody has a better idea then then my plan is to ship in the
> next upload of kmod a file in /etc/modprobe.d/ which uses the
> blacklist directive to prevent automatically loading some file system
> modules.
[…]
> I think that all of these have enough of a niche usage that it would
> not be an unreasonable burden for the affected users to manually load
> the modules when needed (ad hoc or using /etc/modules-load.d/).
In case you do this, I'd like there to be a NEWS.Debian entry about
this, explaining both the justification behind it and how people can work
around it. It could go like this:
-----------------------------------------------------------------------
Since version xyz of kmod the file /etc/modprobe.d/block-unsafe-
filesystems.conf prevents loading of several filesystem modules that are
automatically loaded by udev when inserting a medium that contains one
of them. These filesystems are either known to be unsafe or are not
maintained actively anymore. A deliberately corrupted filesystem
structure could trigger the filesystem driver in the module to crash,
corrupt memory of other kernel components or to cause other problems.
[Adjust to whatever risks are most likely to occur] [Add some links here
for the discussion about that]
In case you rely on using one or more of these filesystems you can either
edit the file /etc/modprobe.d/block-unsafe-filesystems.conf and put a
comment sign before the filesystem in question or add the filesystem to a
file to a file in /etc/modules-load.d/. [Please clarify here as needed]
Please take care not to plug in any device that you do not trust.
-----------------------------------------------------------------------
This is just a rough idea it probably needs several iterations to obtain
a good wording that balances on assessing the risk correctly (without
over or under estimating it). Also the method of circumventing the
blocking may need further explanations. I am not using systemd, so I can
not describe exactly how modules-load.d works. In case you like to use
any of the above wording, feel free to use it under the license of the
packaging of kmod.
I wonder about other kernel modules in other areas of the kernel that
may be automatically loaded when connecting some hardware… especially
some random USB device, but… that appears to me like opening a huge can
of worms. I bet the Linux kernel has more than several hundreds of
specialized USB drivers maybe even more than thousand meanwhile despite
all the USB standards out there?
Linux is not a micro kernel. It was not designed to run drivers in a
restricted and (somewhat) safe environment to begin with. That means
ideally you'd have to audit all the drivers for security issues
regularly or at least after a certain amount of changes made to it. In
case you do not, for some random driver it will be difficult to know for
sure whether it is safe or unsafe to use. Maybe some small filesystem
driver like affs that still receives a patch every now and then is safer
to use than the much more complex BTRFS filesystem driver.¹ Who knows? Of
cause some fuzzing may really help. But it is not a guarantee either.
And then what about other kernel functionally that is loaded as module
on demand that is only rarely used by some people?
So I wonder what body of evidence there is to base a policy decision on
which driver to load or not to load automatically. Without a reliable
body of evidence there is always the risk to either over or under policy
the users of Debian and derived distributions (whose maintainers do not
decide to change such a policy decision again). So I'd argue against
taking the quick route on that to allow the time for a more informed
decision. Maybe start with clear-cut cases likely probably HFS/HFS+
instead of just adding all kinds of other filesystems without even know
whether there is a known exploit. Of course you could go by maintenance
status, however, this can be inaccurate. How to do accurately determine
maintenance status, especially as MAINTAINERS file may not be accurate or
up-to-date at all times? And how many specialized USB drivers are there
that are compiled as modules on Debian kernels that may not be
maintained as well? Disable all of them by default?
Risk assessment is very challenging here, if you ask me.
[1] After a long time finally some RDB partitioning overflow fixes went
into the kernel. The overflow bug could have caused overwriting of data
at a different place of the disk on a different partition than intended
which could mean a two-way data loss of both the written data and the
data that was accidentally overwritten. While this theoretically could
have been used for an exploit by deliberately causing the kernel to
overwrite data at a certain location of the disk, I am not aware of any
existing exploit for this. Such an exploit would only target a quite low
amount of users I bet. See:
Partitions: Amiga RDB partition on 2 TB disk way too big, while OK in
AmigaOS 4.1
https://bugzilla.kernel.org/show_bug.cgi?id=43511
Plus a ton of discussions on various mailing lists, hopefully all linked
in above bug report.
Thanks,
--
Martin
Reply to: