In this one, there’s a heap overflow bug in the legacy_parse_param in the Linux kernel’s fs/fs_context.c program. This parameter is used in Linux filesystems during superblock creation for mount and superblock reconfiguration for a remount. The superblock records all of a filesystem’s characteristics such as file size, block size, empty and filled storage blocks. So, yeah, it’s important. The legacy_parse_param() “PAGE_SIZE - 2 - size” calculation was mistakenly made an unsigned type. This means a large value of “size” results in a high positive value instead of a negative value as expected. Whoops. This, in turn, meant you copy data beyond the memory slab allocated for it. And, as all programmers know, writing beyond the memory your program is supposed to have access to is a terrible thing. One big reason why Rust is being incorporated into Linux is that Rust makes this kind of memory mistake much harder to do. As every C developer knows, it’s all too easy to trip over memory allocation in a C program. So, how bad is it? By the Common Vulnerability Scoring System (CVSS) v3.1 scoring test, it’s a solid 7.7. That’s considered a high-security vulnerability. A local attacker can use it to escalate their user privileges or crash the system. This can be done with a specially crafted program that triggers this integer overflow. That done, it’s trivial to execute arbitrary code and give the attacker root privileges. To exploit it requires the CAP_SYS_ADMIN privilege to be enabled. If that’s the case, an unprivileged local user can open a filesystem that does not support the File System Context application programming interface (API). In this situation, it drops back to legacy handling, and from there, the flaw can escalate an attacker’s system privileges. Exploiting is not as hard to do as you might think. Its discoverer, Linux kernel developer William Liu reports he created exploits against Ubuntu 20.04 and container escape exploits against Google’s hardened Container-Optimized (COS). This security hole was introduced back on Feb 28, 2019, in the Linux 5.1-rc1 kernel. It’s now present in all Linux kernels. Yes, all of them. Fortunately, the patch is in. You can also disable it by disabling user namespaces by setting user.max_user_namespaces to with the following shell code on the Red Hat Linux family.
echo “user.max_user_namespaces=0” > /etc/sysctl.d/userns.confsysctl -p /etc/sysctl.d/userns.conf
On Ubuntu and related distros, you can protect your system with this shellcode:
sysctl -w kernel.unprivileged_userns_clone=0
However, keep in mind that you must have namespace available on containerized Linux distros, such as Red Hat OpenShift Container Platform since it needs this functionality enabled. In these circumstances, you’ll need to patch your Linux distro as soon as your distributor makes the patch available. Stay safe, stay patched. Related stories:
In 2022, security will be priority number one for Linux and open-source developers.It’s time to improve Linux’s security.When open-source developers go bad.
