-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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: Fixed Manufacturer Notification: 2021-09-10 Solution Date: 2021-09-29 Public Disclosure: 2021-10-25 CVE Reference: CVE-2021-3802 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 a denial of service (kernel panic) upon mounting a crafted image. This is especially relevant when mounts can be caused by unprivileged users or are configured to happen automatically and completely unauthorized. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Vulnerability Details: Ext2/3/4 file systems contain a flag describing the way the Linux kernel should behave upon mounts if errors are present on the file system image. This field "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/file manager and directly with "gio(1)" or "udisksctl(1)"). In combination with a manually introduced error in a file system image, this leads to an automatic denial of service upon mounting. On desktop configurations, this allows unprivileged users to cause a kernel panic. It also affects systems where storage media like USB sticks are automatically mounted upon plugging them in, like it is the case for certain embedded systems. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proof of Concept (PoC): The following small ext4 file system image of 512 KiB suffices (formatting e.g. a USB stick with such an image works as well). It sets the error handler to "panic" (see [1]) and manually introduces an error into the image by setting the links_count of the uppermost directory to zero (see [2]). ``` fallocate --length 512KiB 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) or via the different mount helpers. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Solution: It should be noted that this behavior clearly works as designed and is described in the official kernel documentation. Therefore, as has been said before (see e.g. related [4]), the general advice would be to treat unknown file system images as unsafe and to not mount arbitrary untrusted file systems. Run "fsck" before mounting in order to make sure that it does not contain any errors. Nevertheless, SySS GmbH advocates for saner defaults, especially in user-facing components. This particular issue can be mitigated by explicitly specifying the already existing mount option "errors=" (see [3]), which overrides the field value set in the file system itself. For example, it can be specified that the file system should be remounted read-only in case of errors, as seen in the following: 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: Behavior noticed 2021-07-30: Reported to KDE and GNOME development teams In response, patches for both kio and glib were implemented. However, both projects rely mainly on udisks and use own code only as fallback. 2021-09-10: Reported to udisks development team 2021-09-15: Fixed in udisks; part of release 2.9.4 on 2021-09-29 2021-10-25: Public disclosure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ References: [1] http://www.nongnu.org/ext2-doc/ext2.html#s-errors [2] http://www.nongnu.org/ext2-doc/ext2.html#i-links-count [3] https://www.kernel.org/doc/Documentation/filesystems/ext4.txt or `man 5 ext4` [4] https://lwn.net/Articles/755593/ [5] SySS Security Advisory SYSS-2021-045 https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2021-045.txt [6] SySS Responsible Disclosure Policy https://www.syss.de/en/responsible-disclosure-policy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Credits: This security vulnerability was found by Stefan Walter of SySS GmbH. E-Mail: stefan.walter@syss.de 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclaimer: 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 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEdN13zQMXJ3dHDTi+vguzEdo/PhYFAmFb/WMACgkQvguzEdo/ PhYwsA/+Jdcsm4Wq1Nk8HzRXxnOOpVTpPT9Kz14wXEYKOOtsweHgSmGlQzm5ZU0R X7glbd3dDLbfYhDhoC6H+IZDTjG0FiTgHxd52vkzlNZsnaKDDWMCeHxFI706Nzih +vJHnllPEkyxKv1BwVu0c4aAmj2oTUbCd8Oli2j9FR9CtYJ/sqXFTKDJH35quH1q FVi7Ydmim9my+cATubERbx3Qz32m62MoRdk6Wctk+cFxP8SX9P6Rrab7zd/2UrwP tB0WpDbY4EpHK86iIJ8QXpSyqc1pG3r/nJPtWHemCbnqWCOVoIPeKQMw3NkwN192 fr71rFuPi7RVJeAZy/5wjUYbTEavFVr0K+ij03kALgwtdlNQ5Hn98/d74bwyxshZ EVIyLp7FtZ6INiyfnu4clxALTNHWMMFtRgOHoU1cmn5Y7bv50ZkVNEE21Uv+iDkh vQShorg7fVIcpCvIL6IyMval1SXBToeues9fi+CwG0TOYaF/YUeXQL79NGb79mOg yOH1KIx8Jw11KbNxwIV/YLQZkizRc80zWxFioAynhGXoS6jdxiyz4ZK6rj4EMFp/ 1HUmoesgJObQICSfZQylSK1UM4/X6qpiWn8NprzYtmaRia808mPmE4VFHwvvannd Qd1OkKTe1itX8OxT1PThCVwPChVye2G8g/4X0KmbFhFEwNyH5nQ= =X27X -----END PGP SIGNATURE-----