The Qualys Research Team, which uncovered the file system bug, also discovered a size_t-to-int type conversion vulnerability in the Linux kernel’s filesystem. This Linux security hole has been named Sequoia and it’s been designated CVE-2021-33909. Doesn’t sound like much, does it? Au contraire! It can be used against most Linux distributions in their default configurations. And, worse still, any – I repeat, any – unprivileged user can abuse it to gain root privileges. Here’s how it works. We all use filesystems every day, but you probably don’t think about how it works. Who, except for developers, does? In Linux’s case, the file system interface is implemented in a three-layered architecture. There’s the user interface layer; the file system implementation; and the storage device drivers. Within the Linux kernel’s seq_file interface produces virtual files containing sequences of records. Each record must fit into a seq_file buffer. When it runs out of space, it’s just enlarged by doubling its size. That’s not a problem. You’ll run out of memory long before you can hack the system with this. The problem shows up because this size_t variable is also passed to functions whose size argument is a signed 32-bit integer, not a size_t. And that, my friend, while a very large number, can be overrun. Then, as Bharat Jogi, Qualys’ Senior Manager of Vulnerabilities and Signatures, explains, “If an unprivileged local attacker creates, mounts, and deletes a deep directory structure whose total path length exceeds 1GB, and if the attacker open()s and read()s /proc/self/mountinfo, then” through a series of other maneuvers you can write to out of bounds memory. And, with that, you can corrupt data, crash the system, or, worst of all, execute unauthorized code. Alas, there are numerous known hacks that use memory overruns to become the root user and grab control of a computer. In fact, that’s exactly what Qualys security team did. They developed an exploit, which they then used to obtain full root privileges on default installations of Ubuntu 20.04, Ubuntu 20.10, Ubuntu 21.04, Debian 11, and Fedora 34. OK, let’s just admit it. Pretty much any Linux distro is vulnerable to this trick. Is this a great day to be a Linus sysadmin or what? The good news is that while this problem is alive and nasty in any system running the Linux kernel 3.16 through 5.13.x before 5.13.4, patches are available. In fact, I patched my Linux Mint desktop for it, before I even started to write this story. Yes, it’s that bad. Eric Sandeen, Red Hat’s top file system developer, came up with a fix for the problem. Greg Kroah-Hartman, the Linux kernel maintainer for the Linux stable branch, subsequently released the kernel patch for Sequoia on July 20th in the Linux kernel 5.13.4 release. If you can’t upgrade your kernel, you can still mitigate the problem by setting /proc/sys/kernel/unprivileged_userns_clone to 0. This prevents an attacker from mounting a long directory in a user namespace. However, the attacker may still be able to mount a poisonously long directory via Filesystem in Userspace (FUSE). You should also set /proc/sys/kernel/unprivileged_bpf_disabled to 1. This prevents an attacker from loading an eBPF program into the kernel. However, there may be other ways to attack. The only sure way to stop this security hole in its track is to update your kernel. This fix is also available in most Linux distributions now. So, if you’ve been sitting on your hands and not updating your Linux computers, it’s time to get off them and start typing in patching commands. Related Stories:
Nasty Linux systemd security bug revealedMajor Linux RPM problem uncoveredCloudLinux releases UChecker security tool for Linux servers
