Security Issue: gio: Several user-accessible mount-helpers use insecure defaults
Original reporter: Stefan Walter
Dear Sir or Madam,
please find enclosed a Security Advisory concerning insecure default mount options we noticed in several mount helpers (e.g. kio/gio).
At SySS GmbH we deal with discovered security issues responsibly. So to inform the public and our customers we would like to publish our security advisory, ideally when the security vulnerability is fixed or a patch released but, at the latest, on the 13.09.2021, according to our Responsible Disclosure Policy (https://www.syss.de/en/responsible-disclosure-policy). Under special circumstances, we can agree on a different schedule for our publication.
Please let me know how you would like to proceed in remedying this vulnerability. For further information please do not hesitate to contact me.
Best regards, Stefan Walter
-- Stefan Walter IT Security Consultant
SySS GmbH Schaffhausenstraße 77, 72072 Tübingen, Germany Tel: +49 (0)7071 - 40 78 56 - 6231 Mobil: +49 (0)151 - 29 23 56 38 E-Mail: firstname.lastname@example.org Conf. Calls: https://syss.zoom.us/ Web: https://syss.de
PGP-Fingerprint: 74DD 77CD 0317 2777 470D 38BE BE0B B311 DA3F 3E16
Geschäftsführer: Sebastian Schreiber Registergericht: Amtsgericht Stuttgart / HRB 382420 Steuernummer: 86118 / 55809
Advisory ID: SYSS-2021-045 Product: Mount-helpers of various linux distributions and desktop environments Affected Version(s): Linux kernel 5.13.4-arch1-1, gio glib2 2.68.3-1, kio 5.84.0-2, udisks2 2.9.2-1 Tested Version(s): Linux kernel 5.13.4-arch1-1, gio glib2 2.68.3-1, kio 5.84.0-2, udisks2 2.9.2-1 Vulnerability Type: Insecure defaults Risk Level: Low Solution Status: Unknown Manufacturer Notification: 2021-07-30 Solution Date: Unknown Public Disclosure: 2021-09-13 CVE Reference: Not yet assigned Author of Advisory: Stefan Walter, SySS GmbH
Overview: Several user-accessible mount-helpers use insecure defaults which allow ext2/3/4 file systems to cause denial-of-service (kernel panic) on mount of a crafted image. This is especially relevant when mounts can be caused by unprivileged users or are configured to happen automatically and completely unauthorized.
Ext2/3/4 file systems contain a flag describing the way the Linux kernel should
behave on mounts if errors are present on the file system image.
s_errors is part of the superblock, which contains various
metadata about the file system in general. One of its possible values is
kernel panic and halting the machine if an error occurs.
In the default configuration, this option is honored by the Linux kernel, as
well as several mount-helpers used in different desktop environments/linux
distributions (tested on KDE, XFCE, Gnome, in GUI/filemanager and directly with
In combination with a manually introduced error in a file system image, this leads to automatic denial-of-service upon mount.
On desktop configurations this allows unprivileged users to cause a kernel panic. It also effects systems where storage media like USB sticks is automatically mounted upon plugging it in, like it is the case for certain embedded systems.
Proof of Concept (PoC): The following small ext4 file system image of 60 KiB suffices (formatting e.g. an USB stick with such an image works as well). It sets the error handler to `panic` (see ) and manually introduces an error into the image by setting the links_count of the uppermost directory to zero (see ). ``` fallocate --length 60KiB poc.img /sbin/mkfs.ext4 poc.img cat <<'EOF' | /sbin/debugfs -i open -w poc.img set_super_value errors 3 set_inode_field . links_count 0 close -a EOF ``` The kernel panic can be triggered by mounting the image/USB stick, e.g. via sudo mount poc.img $(mktemp -d)
It should be noted that this behaviour clearly works as designed and is
described in the official kernel documentation. Therefore, as has been said
before (see e.g. related ), the general advice would be to treat unknown
file system images as unsafe and do not mount arbitrary untrusted file systems.
fsck before mounting in order to make sure that it does not contain any
Nevertheless, we advocate for saner defaults, especially in user-facing
components. This particular issue can be mitigated by explicitly specifying
the already existing mount option
errors= (see ), which overrides the
field value set in the file system itself. For example, it can be specified
that the fs should be remounted read-only in the case of errors, like so:
mount -t ext4 -o errors=remount-ro $FILESYSTEM $MOUNTPOINT
We recommend that the different desktop environments and user-accessible tools apply this option as default when mounting ext2/3/4 file systems.
Disclosure Timeline: 2021-07-17: Behaviour noticed 2021-07-30: Reported to development teams 2021-09-13: Public disclosure
 https://www.kernel.org/doc/Documentation/filesystems/ext4.txt or
man 5 ext4
 SySS Security Advisory SYSS-2021-045
 SySS Responsible Disclosure Policy
Credits: This security vulnerability was found by Stefan Walter of SySS GmbH. E-Mail: email@example.com Public Key: https://www.syss.de/fileadmin/dokumente/PGPKeys/Stefan_Walter.asc Public Key: https://www.syss.de/kontakt/pgp-keys Key ID: 0xBE0BB311DA3F3E16 Key Fingerprint: 74DD 77CD 0317 2777 470D 38BE BE0B B311 DA3F 3E16
The information provided in this security advisory is provided "as is" and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The latest version of this security advisory is available on the SySS website.
Copyright: Creative Commons - Attribution (by) - Version 3.0 URL: http://creativecommons.org/licenses/by/3.0/deed.en