[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1041552: HFS/HFS+ are insecure



Package: src:linux
Severity: normal

You are totally correct.
Kernel team, please blacklist HFS/HFS+ for automounting.

On Jul 20, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

> Hello!
> 
> On Thu, 2023-07-20 at 18:30 +0100, Matthew Wilcox wrote:
> > On Thu, Jul 20, 2023 at 05:27:57PM +0200, Dmitry Vyukov wrote:
> > > On Thu, 5 Jan 2023 at 17:45, Viacheslav Dubeyko <slava@dubeyko.com> wrote:
> > > > > On Wed, Jan 04, 2023 at 08:37:16PM -0800, Viacheslav Dubeyko wrote:
> > > > > > Also, as far as I can see, available volume in report (mount_0.gz) somehow corrupted already:
> > > > > 
> > > > > Syzbot generates deliberately-corrupted (aka fuzzed) filesystem images.
> > > > > So basically, you can't trust anything you read from the disc.
> > > > > 
> > > > 
> > > > If the volume has been deliberately corrupted, then no guarantee that file system
> > > > driver will behave nicely. Technically speaking, inode write operation should never
> > > > happened for corrupted volume because the corruption should be detected during
> > > > b-tree node initialization time. If we would like to achieve such nice state of HFS/HFS+
> > > > drivers, then it requires a lot of refactoring/implementation efforts. I am not sure that
> > > > it is worth to do because not so many guys really use HFS/HFS+ as the main file
> > > > system under Linux.
> > > 
> > > 
> > > Most popular distros will happily auto-mount HFS/HFS+ from anything
> > > inserted into USB (e.g. what one may think is a charger). This creates
> > > interesting security consequences for most Linux users.
> > > An image may also be corrupted non-deliberately, which will lead to
> > > random memory corruptions if the kernel trusts it blindly.
> > 
> > Then we should delete the HFS/HFS+ filesystems.  They're orphaned in
> > MAINTAINERS and if distros are going to do such a damnfool thing,
> > then we must stop them.
> 
> Both HFS and HFS+ work perfectly fine. And if distributions or users are so
> sensitive about security, it's up to them to blacklist individual features
> in the kernel.
> 
> Both HFS and HFS+ have been the default filesystem on MacOS for 30 years
> and I don't think it's justified to introduce such a hard compatibility
> breakage just because some people are worried about theoretical evil
> maid attacks.
> 
> HFS/HFS+ mandatory if you want to boot Linux on a classic Mac or PowerMac
> and I don't think it's okay to break all these systems running Linux.
> 
> Thanks,
> Adrian
> 
> -- 
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

-- 
ciao,
Marco

Attachment: signature.asc
Description: PGP signature


Reply to: