Bug#1041552: HFS/HFS+ are insecure
On Mar 13, Michael Biebl wrote: > > So I propose this content for a file like > > /usr/lib/udev/rules.d/75-insecure-fs.rules: > Just curious: Why did you pick priority 75? I can't remember. -- ciao, Marco signature.asc Description: PGP signature
Bug#1041552: HFS/HFS+ are insecure
Hi Marco On Sun, 27 Aug 2023 02:34:04 +0200 Marco d'Itri wrote: Control: reassign -1 udisks2 Control: retitle -1 do not mount automatically unmaintained file systems On Jul 20, md wrote: > You are totally correct. > Kernel team, please blacklist HFS/HFS+ for automounting. As discussed on debian-devel@, this policy should not be handled by the kernel because modules autoloading of file systems drivers should not be disabled. So I propose this content for a file like /usr/lib/udev/rules.d/75-insecure-fs.rules: Just curious: Why did you pick priority 75? OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1041552: HFS/HFS+ are insecure
I think the idea that HFS+ is not used on removable device is a bit of a fallacy. I, myself, use this frequently on removable hard drives when moving large data sets back and forth from my Mac. The Mac doesn't easily read ext filesystems, but Linux can read HFS, and the various Microsoft filesystems lose too much metadata. --J > On Jan 10, 2024, at 12:39, Marco d'Itri wrote: > > On Jan 10, Michael Biebl wrote: > >> While we could ship such a udev rule for udisks, I don't think it will >> properly solve the issue. The device will still show up in nautilus, plasma >> etc and mounting is just an additional click away. > The threat model here is: somebody connects a crafted USB stick to > a computer with a locked screen. > > Also, the listed file systems are not used or not used anymore on > removable devices. > Certainly not on removable devices used by regular users. > > -- > ciao, > Marco
Bug#1041552: HFS/HFS+ are insecure
On Jan 10, Michael Biebl wrote: > While we could ship such a udev rule for udisks, I don't think it will > properly solve the issue. The device will still show up in nautilus, plasma > etc and mounting is just an additional click away. The threat model here is: somebody connects a crafted USB stick to a computer with a locked screen. Also, the listed file systems are not used or not used anymore on removable devices. Certainly not on removable devices used by regular users. -- ciao, Marco signature.asc Description: PGP signature
Bug#1041552: HFS/HFS+ are insecure
On Sun, 27 Aug 2023 02:34:04 +0200 Marco d'Itri wrote: So I propose this content for a file like /usr/lib/udev/rules.d/75-insecure-fs.rules: While we could ship such a udev rule for udisks, I don't think it will properly solve the issue. The device will still show up in nautilus, plasma etc and mounting is just an additional click away. The UI would have to updated to present some kind of information to the user, that mounting the FS is potentially unsafe and asking the users for extra confirmation. This would need more design work though and buy in from the desktop environments like say GNOME or KDE. Tagging such FSes via udev rules seems like a reasonable idea though. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1041552: HFS/HFS+ are insecure
On Sun, 27 Aug 2023 02:34:04 +0200 Marco d'Itri wrote:
Control: reassign -1 udisks2
Control: retitle -1 do not mount automatically unmaintained file systems
On Jul 20, md wrote:
> You are totally correct.
> Kernel team, please blacklist HFS/HFS+ for automounting.
As discussed on debian-devel@, this policy should not be handled by the
kernel because modules autoloading of file systems drivers should not be
disabled.
So I propose this content for a file like
/usr/lib/udev/rules.d/75-insecure-fs.rules:
# Do not automatically mount these file systems because their drivers are
# marked as "orphan" or "odd fixes" in the kernel MAINTAINERS file and so
# are more at risk of having security-sensitive defects which could be
# exploited by a crafted file system.
SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="affs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="ecryptfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="efs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="jffs2", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="jfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="qnx6", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="sysv", ENV{UDISKS_AUTO}="0"
LABEL="udisks_insecure_fs_end"
I asked udisks upstream for their input, see
https://github.com/storaged-project/udisks/issues/1239
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1041552: HFS/HFS+ are insecure
On Sunday, 27 August 2023 12:39:11 CEST Marco d'Itri wrote: > > Previously not knowing about that status, I looked up the commits where > > the > > status was set to "odd fixes" and found that for some the reason was that > > the maintainer didn't have the hardware to test it themselves. > > I do not think that's the same as 'unmaintained'. > > It means that they are not tested enough... I consider that a too broad and blanked statement, which was why I replied. I started explaining further (but removed it again), but I don't think that'll have any effect, so I'll leave it at this. o/ signature.asc Description: This is a digitally signed message part.
Bug#1041552: HFS/HFS+ are insecure
On Aug 27, Diederik de Haas wrote: > While I agree that "orphan" does mean that it is NOT actively maintained, > AFAICT the situation is a bit more blurry for "odd fixes". All these file systems are either rare enough and/or not used on removable media, so I do not believe that it is unreasonable to ask the few users that want them to be mounted automatically to disable this policy with a symlink like ln -s /dev/null /etc/udev/rules.d/75-insecure-fs.rules . > Previously not knowing about that status, I looked up the commits where the > status was set to "odd fixes" and found that for some the reason was that the > maintainer didn't have the hardware to test it themselves. > I do not think that's the same as 'unmaintained'. It means that they are not tested enough... > I'm not sure if it would actually result in unbootable systems, but I do think > a bit more care should be taken before blacklisting modules. Did you actually read the thread? No modules are being blacklisted, the plan is just to stop udisks2 from automatically mounting such removable media. I am quite sure that routers file systems are not mounted with udisks2. -- ciao, Marco signature.asc Description: PGP signature
Bug#1041552: HFS/HFS+ are insecure
On Sunday, 27 August 2023 02:34:04 CEST Marco d'Itri wrote: > So I propose this content for a file like > /usr/lib/udev/rules.d/75-insecure-fs.rules: > > # Do not automatically mount these file systems because their drivers are > # marked as "orphan" or "odd fixes" in the kernel MAINTAINERS file and so On Sunday, 23 July 2023 02:38:41 CEST Ben Hutchings wrote: > 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. While I agree that "orphan" does mean that it is NOT actively maintained, AFAICT the situation is a bit more blurry for "odd fixes". Previously not knowing about that status, I looked up the commits where the status was set to "odd fixes" and found that for some the reason was that the maintainer didn't have the hardware to test it themselves. I do not think that's the same as 'unmaintained'. The main reason I looked into this was the "jffs2" entry and for that there was no reason given. But I know it is used in routers and SBCs and I saw recently a patch come by related to that, which was accepted so should be part of the 6.6 kernel. Doing `gitk -- fs/jffs2/` also revealed that there were commits in 6.5, 6.4 and 6.3 at which point I stopped investigating that as it was clear to me that it was anything but unmaintained. Looking into MAINTAINERS, I also saw that `drivers/char/hw_random/` has the "Odd fixes" status... I'm not sure if it would actually result in unbootable systems, but I do think a bit more care should be taken before blacklisting modules. signature.asc Description: This is a digitally signed message part.
Bug#1041552: HFS/HFS+ are insecure
Control: reassign -1 udisks2
Control: retitle -1 do not mount automatically unmaintained file systems
On Jul 20, md wrote:
> You are totally correct.
> Kernel team, please blacklist HFS/HFS+ for automounting.
As discussed on debian-devel@, this policy should not be handled by the
kernel because modules autoloading of file systems drivers should not be
disabled.
So I propose this content for a file like
/usr/lib/udev/rules.d/75-insecure-fs.rules:
# Do not automatically mount these file systems because their drivers are
# marked as "orphan" or "odd fixes" in the kernel MAINTAINERS file and so
# are more at risk of having security-sensitive defects which could be
# exploited by a crafted file system.
SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="affs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="ecryptfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="efs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="jffs2", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="jfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="qnx6", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="sysv", ENV{UDISKS_AUTO}="0"
LABEL="udisks_insecure_fs_end"
--
ciao,
Marco
signature.asc
Description: PGP signature
Bug#1041552: HFS/HFS+ are insecure
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.
signature.asc
Description: This is a digitally signed message part
Bug#1041552: 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.
Bug#1041552: HFS/HFS+ are insecure
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 > > > > signature.asc Description: This is a digitally signed message part.
Bug#1041552: HFS/HFS+ are insecure
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 > signature.asc Description: This is a digitally signed message part.
Bug#1041552: HFS/HFS+ are insecure
Hi Marco, hi, Marco d'Itri - 21.07.23, 10:55:39 CEST: > On Jul 21, Matthew Garrett 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
Bug#1041552: HFS/HFS+ are insecure
Looks reasonable. Le vendredi 21 juillet 2023 à 10:55 +0200, Marco d'Itri a écrit : > On Jul 21, Matthew Garrett 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/). >
Bug#1041552: HFS/HFS+ are insecure
On Jul 21, Matthew Garrett 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 signature.asc Description: PGP signature
