Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #108685 > unrolled thread

Bug#1041552: HFS/HFS+ are insecure

Back to article view | Back to linux.debian.devel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1041552: HFS/HFS+ are insecure Marco d'Itri <md@Linux.IT> - 2023-07-20 20:10 +0200
    Re: HFS/HFS+ are insecure Matthew Garrett <mjg59@srcf.ucam.org> - 2023-07-21 10:30 +0200
      Re: HFS/HFS+ are insecure Marco d'Itri <md@Linux.IT> - 2023-07-21 11:00 +0200
        Re: HFS/HFS+ are insecure Magissia <debianlist@magissia.com> - 2023-07-21 11:10 +0200
        Re: HFS/HFS+ are insecure Martin Steigerwald <martin@lichtvoll.de> - 2023-07-21 12:10 +0200
        Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 13:00 +0200
          Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 13:10 +0200
        Re: HFS/HFS+ are insecure Matthew Garrett <mjg59@srcf.ucam.org> - 2023-07-21 19:40 +0200
          Re: HFS/HFS+ are insecure Ben Hutchings <ben@decadent.org.uk> - 2023-07-23 02:40 +0200
      Re: HFS/HFS+ are insecure Magissia <debianlist@magissia.com> - 2023-07-21 11:20 +0200
      Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 12:00 +0200
        Re: HFS/HFS+ are insecure Marco d'Itri <md@Linux.IT> - 2023-07-21 12:20 +0200
          Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 12:30 +0200
            Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 13:10 +0200
            Re: HFS/HFS+ are insecure Paul Wise <pabs@debian.org> - 2023-07-22 09:50 +0200
              Re: HFS/HFS+ are insecure Matthew Garrett <mjg59@srcf.ucam.org> - 2023-07-22 10:00 +0200
                Re: HFS/HFS+ are insecure Jonas Smedegaard <jonas@jones.dk> - 2023-07-22 10:30 +0200
                  Re: HFS/HFS+ are insecure Matthew Garrett <mjg59@srcf.ucam.org> - 2023-07-22 10:40 +0200
                Re: HFS/HFS+ are insecure Jeremy Stanley <fungi@yuggoth.org> - 2023-07-22 14:50 +0200
                  Re: HFS/HFS+ are insecure Paul Wise <pabs@debian.org> - 2023-07-25 06:40 +0200
                Re: HFS/HFS+ are insecure Paul Wise <pabs@debian.org> - 2023-07-25 06:30 +0200
        Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 12:20 +0200
        Re: HFS/HFS+ are insecure Bastien Roucariès <bastien.roucaries@cyu.fr> - 2023-07-21 12:30 +0200
        Re: HFS/HFS+ are insecure Seth Arnold <seth.arnold@canonical.com> - 2023-07-21 23:20 +0200

Page 1 of 2  [1] 2  Next page →

#108685 — Bug#1041552: HFS/HFS+ are insecure

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#108686 — Re: HFS/HFS+ are insecure

On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote:
> Package: src:linux
> Severity: normal
> 
> 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 
the only way for the kernel to disable automounting would be to disable 
the drivers entirely (which we don't want to do), so this probably needs 
to be assigned elsewhere rather than being a linux bug.

(Or, alternatively, we could move hfs(+) support to FUSE and provide 
extremely tight seccomp policies around them, and then drop kernel 
support, but even though this has been talked about a bunch I haven't 
seen anyone try to implement it)

[toc] | [prev] | [next] | [standalone]

#108687 — Re: HFS/HFS+ are insecure

[Multipart message — attachments visible in raw view] — view raw

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.

By looking at the MAINTAINERS file I have identified these file systems 
marked as "orphan" and "odd fixes":

efs
hfs
hfaplus
qnx6
sysv

affs
ecryptfs
jffs2
jfs

And I think that I can also safely add a few more which while actively 
maintained I believe are only used in a retrocomputing context or are 
generally uncommon anyway:

befs
bfs
hpfs
omfs
qnx4
reiserfs
spu
ufs

Did i miss anything?

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/).

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#108688 — Re: HFS/HFS+ are insecure

Looks reasonable.

Le vendredi 21 juillet 2023 à 10:55 +0200, Marco d'Itri a écrit :
> 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.
> 
> By looking at the MAINTAINERS file I have identified these file
> systems 
> marked as "orphan" and "odd fixes":
> 
> efs
> hfs
> hfaplus
> qnx6
> sysv
> 
> affs
> ecryptfs
> jffs2
> jfs
> 
> And I think that I can also safely add a few more which while
> actively 
> maintained I believe are only used in a retrocomputing context or
> are 
> generally uncommon anyway:
> 
> befs
> bfs
> hpfs
> omfs
> qnx4
> reiserfs
> spu
> ufs
> 
> Did i miss anything?
> 
> 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/).
> 

[toc] | [prev] | [next] | [standalone]

#108691 — 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

[toc] | [prev] | [next] | [standalone]

#108697 — Re: HFS/HFS+ are insecure

[Multipart message — attachments visible in raw view] — view raw

Le vendredi 21 juillet 2023, 08:55:39 UTC Marco d'Itri a écrit :
> efs
https://pypi.org/project/qnxmount/ claim to mount it. Check
> hfs
https://github.com/0x09/hfsfuse
> hfaplus
https://github.com/0x09/hfsfuse
> qnx6
Fuse ro filesystem https://pypi.org/project/qnxmount/ better support then kernel one
> sysv
no fuse equivalent may be easier to port from (net)?bsd source to fuse or use the method of qnxmount
> 
> affs
no fuse equivalent but a grub filesystem may be ported to fuse
> ecryptfs
no fuse equivalent
> jffs2
no fuse equivalent
> jfs
no fuse equivalent but a grub filesystem may be ported to fuse
> 
> And I think that I can also safely add a few more which while actively 
> maintained I believe are only used in a retrocomputing context or are 
> generally uncommon anyway:
> 
> befs
A fuse module seems to be avalaible https://www.haiku-os.org/guides/daily-tasks/access_bfs_with_fuse/
> bfs
no fuse equivalent
> hpfs
no fuse
> omfs
https://github.com/bcopeland/omfs_fuse/
> qnx4
Maybe Fuse ro filesystem https://pypi.org/project/qnxmount/
> reiserfs
so incomplete work using grub filesystem https://github.com/albertz/reiserfs-fuse
> spu
This one is a virtual fs for powerpc should be dropped of the list
> ufs
https://github.com/mkatiyar/fuse-ufs2
> 

[toc] | [prev] | [next] | [standalone]

#108699 — Re: HFS/HFS+ are insecure

[Multipart message — attachments visible in raw view] — view raw

Le vendredi 21 juillet 2023, 10:52:17 UTC Bastien Roucariès a écrit :
> Le vendredi 21 juillet 2023, 08:55:39 UTC Marco d'Itri a écrit :
> > efs
> https://pypi.org/project/qnxmount/ claim to mount it. Check
> > hfs
> https://github.com/0x09/hfsfuse
Corrected not supported by this package may be emulated by using user space hfs tools ?
> > hfaplus
> https://github.com/0x09/hfsfuse
> > qnx6
> Fuse ro filesystem https://pypi.org/project/qnxmount/ better support then kernel one
> > sysv
> no fuse equivalent may be easier to port from (net)?bsd source to fuse or use the method of qnxmount
> > 
> > affs
> no fuse equivalent but a grub filesystem may be ported to fuse
> > ecryptfs
> no fuse equivalent
> > jffs2
> no fuse equivalent
> > jfs
> no fuse equivalent but a grub filesystem may be ported to fuse
> > 
> > And I think that I can also safely add a few more which while actively 
> > maintained I believe are only used in a retrocomputing context or are 
> > generally uncommon anyway:
> > 
> > befs
> A fuse module seems to be avalaible https://www.haiku-os.org/guides/daily-tasks/access_bfs_with_fuse/
> > bfs
> no fuse equivalent
> > hpfs
> no fuse
> > omfs
> https://github.com/bcopeland/omfs_fuse/
> > qnx4
> Maybe Fuse ro filesystem https://pypi.org/project/qnxmount/
> > reiserfs
> so incomplete work using grub filesystem https://github.com/albertz/reiserfs-fuse
> > spu
> This one is a virtual fs for powerpc should be dropped of the list
> > ufs
> https://github.com/mkatiyar/fuse-ufs2
> > 
> 
> 

[toc] | [prev] | [next] | [standalone]

#108707 — Re: HFS/HFS+ are insecure

On Fri, Jul 21, 2023 at 10:55:39AM +0200, Marco d'Itri wrote:

> 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 this would break any existing fstab entries that reference hfs 
and hfsplus, and the convenient way to integrate Linux boot with x86 
Macs is certainly to have an hfsplus EFI partition so this may be a 
legitimate use-case. It also means that anyone who has a need to use one 
of these filesystems in a static manner is vulnerable to automount 
attacks using them.

Completely untested, but I think something along the lines of:

SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
LABEL="udisks_insecure_fs_end"

in a udev fragment should work? Any static fstab or mount units should 
still work, but it should disable udisks automounting regardless of the 
desktop agent involved, even if the fs modules are already loaded.

[toc] | [prev] | [next] | [standalone]

#108723 — Re: HFS/HFS+ are insecure

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2023-07-21 at 18:35 +0100, Matthew Garrett wrote:
> On Fri, Jul 21, 2023 at 10:55:39AM +0200, Marco d'Itri wrote:
> 
> > 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 this would break any existing fstab entries that reference hfs 
> and hfsplus, and the convenient way to integrate Linux boot with x86 
> Macs is certainly to have an hfsplus EFI partition so this may be a 
> legitimate use-case. It also means that anyone who has a need to use one 
> of these filesystems in a static manner is vulnerable to automount 
> attacks using them.

Right, auto-loading of filesystems has to keep working.  And since
mount() of arbitrary filesystems is restricted to root (CAP_NET_ADMIN
in the initial namespace), we should let the callers apply a block- or
allow-list.

The reason we have to disable auto-loading of network protocols is that
socket creation is generally an unprivileged operation, so there's no
trusted user-space that can apply the policy (besides kmod).

> Completely untested, but I think something along the lines of:
> 
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
> LABEL="udisks_insecure_fs_end"
> 
> in a udev fragment should work? Any static fstab or mount units should 
> still work, but it should disable udisks automounting regardless of the 
> desktop agent involved, even if the fs modules are already loaded.

I agree we should not have UDisks probing for any of the (many) kernel
filesystems that aren't being actively maintained including responding
to security issues.

Beyond that, I would also like to see libmount limiting the filesystems
that it will probe when the fstab type is "auto".  But since UDisks
normally handles mounting for unprivileged users, that's probably less
of a concern.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.

[toc] | [prev] | [next] | [standalone]

#108689 — Re: HFS/HFS+ are insecure

If an official procedure to disable the driver completely is documented
and hosted from an official debian server it would be, in my opinion,
an acceptable solution.

Users would have a copy-pastable procedure to disable HFS if the risk
is intolerable to them, sysadmin would have an official page to explain
why they disabled it and having users disabling a driver might add
leverage to potential effort to port this file system support out of
kernel with FUSE.


Le vendredi 21 juillet 2023 à 09:20 +0100, Matthew Garrett a écrit :
> On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote:
> > Package: src:linux
> > Severity: normal
> > 
> > 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 
> the only way for the kernel to disable automounting would be to
> disable 
> the drivers entirely (which we don't want to do), so this probably
> needs 
> to be assigned elsewhere rather than being a linux bug.
> 
> (Or, alternatively, we could move hfs(+) support to FUSE and provide 
> extremely tight seccomp policies around them, and then drop kernel 
> support, but even though this has been talked about a bunch I
> haven't 
> seen anyone try to implement it)
> 

[toc] | [prev] | [next] | [standalone]

#108690 — Re: HFS/HFS+ are insecure

[Multipart message — attachments visible in raw view] — view raw

Le vendredi 21 juillet 2023, 08:20:12 UTC Matthew Garrett a écrit :
Hi
> On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote:
> > Package: src:linux
> > Severity: normal
> > 
> > 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 
> the only way for the kernel to disable automounting would be to disable 
> the drivers entirely (which we don't want to do), so this probably needs 
> to be assigned elsewhere rather than being a linux bug.
> 
> (Or, alternatively, we could move hfs(+) support to FUSE and provide 
> extremely tight seccomp policies around them, and then drop kernel 
> support, but even though this has been talked about a bunch I haven't 
> seen anyone try to implement it)
I vaguely remember that someone implement a fuse over uml (user space linux)

I used it last time to read in user space some crappy filesystem

I somebody has better memory than me, it could be an idea

Bastien

> 
> 

[toc] | [prev] | [next] | [standalone]

#108692 — Re: HFS/HFS+ are insecure

[Multipart message — attachments visible in raw view] — view raw

On Jul 21, Bastien Roucariès <rouca@debian.org> wrote:

> Ok found it call mountlo outdated 
> will need a small patch for linux uml, but may be worthwhile
> Last version seems to be outdated 0.6 and carried by slitaz distribution.
> May be time to revive it
It looks like a good long term solution, but as long as there are 
insecure file systems in the kernel they should be disabled by default 
so these are really different issues.

I remember noise from the systemd people about mounting removable media 
using user space drivers, but I do not think that anybody is working on 
this.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#108695 — Re: HFS/HFS+ are insecure

[Multipart message — attachments visible in raw view] — view raw

Le vendredi 21 juillet 2023, 10:17:13 UTC Marco d'Itri a écrit :
> On Jul 21, Bastien Roucariès <rouca@debian.org> wrote:
> 
> > Ok found it call mountlo outdated 
> > will need a small patch for linux uml, but may be worthwhile
> > Last version seems to be outdated 0.6 and carried by slitaz distribution.
> > May be time to revive it
> It looks like a good long term solution, but as long as there are 
> insecure file systems in the kernel they should be disabled by default 
> so these are really different issues.

No it is not a long term solution. Long term solution will be to push under fuse these filesystem. This a (short term)/(medium term band aid) solution.

I agree with you about disabling these modules

linux uml work on i386/amd64/ppc (by memory) so it could help for some filesystem particularly hfs

I do not understand why uml is not part of main kernel build maybe it is time to get it.

The plan could be:
- build uml along the main kernel (if possible)
- try to get merged old mountlo kernel support
- push to uml only these insecure filesystem
- long term try to push these to pure userspace or drop

What do you think ?

rouca

> 
> I remember noise from the systemd people about mounting removable media 
> using user space drivers, but I do not think that anybody is working on 
> this.
> 
> 

[toc] | [prev] | [next] | [standalone]

#108700 — Re: HFS/HFS+ are insecure

[Multipart message — attachments visible in raw view] — view raw

Le vendredi 21 juillet 2023, 10:28:00 UTC Bastien Roucariès a écrit :
> Le vendredi 21 juillet 2023, 10:17:13 UTC Marco d'Itri a écrit :
> > On Jul 21, Bastien Roucariès <rouca@debian.org> wrote:
> > 
> > > Ok found it call mountlo outdated 
> > > will need a small patch for linux uml, but may be worthwhile
> > > Last version seems to be outdated 0.6 and carried by slitaz distribution.
> > > May be time to revive it
> > It looks like a good long term solution, but as long as there are 
> > insecure file systems in the kernel they should be disabled by default 
> > so these are really different issues.
> 
> No it is not a long term solution. Long term solution will be to push under fuse these filesystem. This a (short term)/(medium term band aid) solution.
> 
> I agree with you about disabling these modules
> 
> linux uml work on i386/amd64/ppc (by memory) so it could help for some filesystem particularly hfs
> 
> I do not understand why uml is not part of main kernel build maybe it is time to get it.
> 
> The plan could be:
> - build uml along the main kernel (if possible)
> - try to get merged old mountlo kernel support
> - push to uml only these insecure filesystem
> - long term try to push these to pure userspace or drop

According to the other thread only these fs should be supported using this method:
- hfs (not hfs+) but pure user space tools exist
-sysv
-affs
-ecryptfs
- jffs2
- jfs
- bfs
- reiserfs

Rouca

> 
> What do you think ?
> 
> rouca
> 
> > 
> > I remember noise from the systemd people about mounting removable media 
> > using user space drivers, but I do not think that anybody is working on 
> > this.
> > 
> > 
> 
> 

[toc] | [prev] | [next] | [standalone]

#108713 — Re: HFS/HFS+ are insecure

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2023-07-21 at 10:28 +0000, Bastien Roucariès wrote:

> Long term solution will be to push under fuse these filesystem.
> This a (short term)/(medium term band aid) solution.

That still potentially exposes insecure code to untrusted data, just in
a user context rather than a kernel context. The same goes for uml +
fuse + namespaces, and even guestfs VMs. You can move the data and code
to different contexts, but that doesn't change the fundamental issue.

Disabling auto-mounting and for manual GUI mounts, requesting users
confirm they trust the filesystem they are mounting would avoid that as
much as is reasonably possible without entirely deleting the code and
without breaking the use-cases of people who need the filesystem code. 

Of course sandboxing the code for those who need it is good too, so
probably we need both, along with ways to disable the mitigations.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#108714 — Re: HFS/HFS+ are insecure

On Sat, Jul 22, 2023 at 03:41:58PM +0800, Paul Wise wrote:

> That still potentially exposes insecure code to untrusted data, just in
> a user context rather than a kernel context. The same goes for uml +
> fuse + namespaces, and even guestfs VMs. You can move the data and code
> to different contexts, but that doesn't change the fundamental issue.

That's still a huge win! You can seccomp it, you can assign LSM 
restrictions, you can significantly reduce the risk associated with 
mounting an untrusted filesystem. We have many more controls in a user 
context than we do in a kernel context.
 
> Disabling auto-mounting and for manual GUI mounts, requesting users
> confirm they trust the filesystem they are mounting would avoid that as
> much as is reasonably possible without entirely deleting the code and
> without breaking the use-cases of people who need the filesystem code. 

When is a user going to plug in a USB stick and *not* click that button? 
I'm not analysing a filesystem by hand to check whether it's trustworthy 
before I want it mounted. There's no reason to automount when the screen 
is locked and presenting a dialog in the case where one was plugged in 
and then the screen unlocked is reasonable, but that just makes no sense 
as generic behaviour.

[toc] | [prev] | [next] | [standalone]

#108715 — Re: HFS/HFS+ are insecure

[Multipart message — attachments visible in raw view] — view raw

Quoting Matthew Garrett (2023-07-22 09:54:59)
> On Sat, Jul 22, 2023 at 03:41:58PM +0800, Paul Wise wrote:
> > Disabling auto-mounting and for manual GUI mounts, requesting users
> > confirm they trust the filesystem they are mounting would avoid that
> > as much as is reasonably possible without entirely deleting the code
> > and without breaking the use-cases of people who need the filesystem
> > code. 
> 
> When is a user going to plug in a USB stick and *not* click that
> button? 

When the user had plugged in a coworker's phone they were asked to please
charge.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#108716 — Re: HFS/HFS+ are insecure

On Sat, Jul 22, 2023 at 10:21:47AM +0200, Jonas Smedegaard wrote:
> Quoting Matthew Garrett (2023-07-22 09:54:59)
> > On Sat, Jul 22, 2023 at 03:41:58PM +0800, Paul Wise wrote:
> > > Disabling auto-mounting and for manual GUI mounts, requesting users
> > > confirm they trust the filesystem they are mounting would avoid that
> > > as much as is reasonably possible without entirely deleting the code
> > > and without breaking the use-cases of people who need the filesystem
> > > code. 
> > 
> > When is a user going to plug in a USB stick and *not* click that
> > button? 
> 
> When the user had plugged in a coworker's phone they were asked to please
> charge.

We're a long way down the social engineering chain there - I think that 
turns into a question of how many people are going to benefit from not 
automounting because of that case vs the number who benefit from the 
convenience under normal circumstances.

[toc] | [prev] | [next] | [standalone]

#108718 — Re: HFS/HFS+ are insecure

[Multipart message — attachments visible in raw view] — view raw

On 2023-07-22 08:54:59 +0100 (+0100), Matthew Garrett wrote:
[...]
> When is a user going to plug in a USB stick and *not* click that
> button? I'm not analysing a filesystem by hand to check whether
> it's trustworthy before I want it mounted. There's no reason to
> automount when the screen is locked and presenting a dialog in the
> case where one was plugged in and then the screen unlocked is
> reasonable, but that just makes no sense as generic behaviour.

When the user has plugged in something that they don't realize
contains a USB storage device, perhaps because it's attached to an
internal hub within a device which has other purposes.

I've read about unsuspecting users buying/borrowing USB chargers and
cables which contain malicious widgets designed to backdoor systems.
Maybe it's urban legend because I don't personally know anyone who's
said they've had machines compromised that way, and most probably
target Windows/iOS/Android anyway even if they are in circulation,
but since the majority of my portable computing devices charge over
USB these days I try to be conscious of it and never plug into the
"convenient" charging ports supplied in airports, airplanes, hotel
rooms, conference rooms... I just bring my own chargers with me.

Also, while the risks of hacked USB devices isn't limited to
exploiting filesystem drivers (backdoored keyboards apparently also
exist, for example), I tend to not configure hotplug automounting
more for preference of having direct control over the system's
behavior. I would much rather explicitly call the mount command and
be able to decide where in the file tree it gets added, on the rare
occasion that I do actually need to plug in a storage peripheral for
some reason. I get that I'm probably an exception, but there are
definitely users who simply find automounting behavior annoying,
beyond any potential security concerns.
-- 
Jeremy Stanley

[toc] | [prev] | [next] | [standalone]

#108737 — Re: HFS/HFS+ are insecure

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2023-07-22 at 12:11 +0000, Jeremy Stanley wrote:

> When the user has plugged in something that they don't realize
> contains a USB storage device, perhaps because it's attached to an
> internal hub within a device which has other purposes.

Probably it would be a good idea for Debian GNOME to install USB Guard
by default to mitigate this threat. I haven't evaluated how user
friendly the GNOME management of it is though, nor whether the
interface results in bad security decisions by users. With USB input
devices on desktop systems, usbguard makes it easy to get yourself
locked out and need to force a reboot, as I found out the hard way.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.devel

csiph-web