KERNEL WATCH
Jon Masters summarises the latest happenings in the Linux kernel, so that you don’t have to.
Linus Torvalds has announced several Release Candidate (RC) kernels for what will become 5.14 by the time you read this. The 5.14-rc4 kernel (and later) include an important fix to the handling of pipes that’s required to properly fix a regression that had affected Android.
The regression occurred because applications were assuming certain semantic behaviour not part of the specification, but instead part of the existing implementation. In such cases, Linux will always aim not to break userspace at almost all costs, even if applications are using an interface incorrectly. The only time this isn’t true is when a breakage is so isolated that it’s known not to impact anyone, or when a security vulnerability necessitates some kind of unavoidable impact upon userspace. This is why Linus regularly asks developers to test his RC releases. He wants to know about this kind of breakage in time to fix it before it goes into lots of Linux distributions.
There were a number of security issues over the past month. In a moment, we’ll take a look at one of them in more depth. We’ll also draw attention to a blog post from Kees Cook in which he walks through the need for greater investment into improving upstream: https://security.googleblog.com/2021/08/ linux-kernel-security-done-right.html.
Sequoia
Recently, the folks at Qualys reached out to the Linux kernel community to let everyone know that they’d discovered a local root exploit vulnerability that had been lurking in plain sight since 2014. The vulnerability allows an untrusted local user to gain root by exploiting an erroneous numeric conversion from size_t (a 64-bit signed value on most platforms) to an int (a 32-bit signed value on the same platforms). Since this is a critical security issue, fixes were coordinated among the many impacted vendors and released simultaneously.
The detail of the vulnerability makes for interesting reading. Essentially, the team rely on the size_t-to-int bug in the kernel’s seqfile mechanism (hence the reason for the brandname “Sequoia”). Within the kernel’s /proc procfs “pseudo” filesystem, entries aren’t backed by disk storage but instead are created as they are read. Among the many users of procfs is the /proc/self/mountinfo file that displays mounted filesystems. When a suitably ridiculous path is created (over 1GB in the filename path) and mounted by a user, reads of this file to ascertain mount info will result in corruption of kernel memory.
An attacker can exploit this corruption, since the kernel will write the text //deleted into a memory location that can be calculated. As a result, it’s possible to arrange to load an eBPF program that will be subtly corrupted by the kernel so that the normal security checks are no longer applied. The attacker has just enough control over the corrupted BPF program to overwrite the location of the /sbin/modprobe command the kernel will run when detecting new hardware with a different program. That program is run with root privileges next time a hardware event of any kind occurs.