{"id":1497,"date":"2021-04-05T16:24:07","date_gmt":"2021-04-05T23:24:07","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=1497"},"modified":"2022-04-04T17:01:45","modified_gmt":"2022-04-05T00:01:45","slug":"security-things-in-linux-v5-9","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2021\/04\/05\/security-things-in-linux-v5-9\/","title":{"rendered":"security things in Linux v5.9"},"content":{"rendered":"

Previously: v5.8<\/a><\/p>\n

Linux v5.9 was released in October, 2020<\/a>. Here\u2019s my summary of various security things that I found interesting:<\/p>\n

seccomp user_notif file descriptor injection<\/strong>
\nSargun Dhillon added the ability for SECCOMP_RET_USER_NOTIF<\/code> filters to inject file descriptors into the target process<\/a> using SECCOMP_IOCTL_NOTIF_ADDFD<\/code>. This lets container managers fully emulate syscalls like open()<\/code> and connect()<\/code>, where an actual file descriptor is expected to be available after a successful syscall. In the process I fixed<\/a> a couple bugs<\/a> and refactored<\/a> the file descriptor receiving code.<\/p>\n

zero-initialize stack variables with Clang<\/strong>
\nWhen Alexander Potapenko landed support for Clang’s automatic variable initialization<\/a>, it did so with a byte pattern designed to really stand out in kernel crashes. Now he’s added support for doing zero initialization<\/a> via CONFIG_INIT_STACK_ALL_ZERO<\/code>, which besides actually being faster, has a few behavior benefits as well. “Unlike pattern initialization, which has a higher chance of triggering existing bugs, zero initialization provides safe defaults for strings, pointers, indexes, and sizes.” Like the pattern initialization, this feature stops entire classes of uninitialized stack variable flaws.<\/p>\n

common syscall entry\/exit routines<\/strong>
\nThomas Gleixner created architecture-independent code to do syscall entry\/exit<\/a>, since much of the kernel’s work during a syscall entry and exit is the same. There was no need to repeat this in each architecture, and having it implemented separately meant bugs (or features) might only get fixed (or implemented) in a handful of architectures. It means that features like seccomp become much easier to build since it wouldn’t need per-architecture implementations any more. Presently only x86 has switched over to the common routines<\/a>.<\/p>\n

SLAB kfree()<\/code> hardening<\/strong>
\nTo reach CONFIG_SLAB_FREELIST_HARDENED<\/code> feature-parity with the SLUB heap allocator, I added naive double-free detection<\/a> and the ability to detect cross-cache freeing<\/a> in the SLAB allocator. This should keep a class of type-confusion bugs from biting kernels using SLAB. (Most distro kernels use SLUB, but some smaller devices prefer the slightly more compact SLAB, so this hardening is mostly aimed at those systems.)<\/p>\n

new CAP_CHECKPOINT_RESTORE<\/code> capability<\/strong>
\nAdrian Reber added the new CAP_CHECKPOINT_RESTORE<\/code> capability<\/a>, splitting this functionality off of CAP_SYS_ADMIN<\/code>. The needs for the kernel to correctly checkpoint and restore a process (e.g. used to move processes between containers) continues to grow, and it became clear that the security implications were lower than those of CAP_SYS_ADMIN<\/code> yet distinct from other capabilities. Using this capability is now the preferred method for doing things like changing \/proc\/self\/exe<\/code><\/a>.<\/p>\n

debugfs<\/code> boot-time visibility restriction<\/strong>
\nPeter Enderborg added the debugfs<\/code> boot parameter<\/a> to control the visibility of the kernel’s debug filesystem. The contents of debugfs continue to be a common area of sensitive information being exposed to attackers. While this was effectively possible by unsetting CONFIG_DEBUG_FS<\/code>, that wasn’t a great approach for system builders needing a single set of kernel configs (e.g. a distro kernel), so now it can be disabled at boot time.<\/p>\n

more seccomp architecture support<\/strong>
\nMichael Karcher implemented the SuperH seccomp hooks<\/a>, Guo Ren implemented the C-SKY seccomp hooks<\/a>, and Max Filippov implemented the xtensa seccomp hooks<\/a>. Each of these included the ever-important updates to the seccomp regression testing suite in the kernel selftests.<\/p>\n

stack protector support for RISC-V<\/strong>
\nGuo Ren implemented -fstack-protector<\/code> (and -fstack-protector-strong<\/code>) support for RISC-V<\/a>. This is the initial global-canary support while the patches to GCC to support per-task canaries is getting finished (similar to the per-task canaries done for arm64). This will mean nearly all stack frame write overflows are no longer useful to attackers on this architecture. It’s nice to see this finally land for RISC-V, which is quickly approaching architecture feature parity with the other major architectures in the kernel.<\/p>\n

new tasklet<\/code> API<\/strong>
\nRomain Perier and Allen Pais introduced a new tasklet<\/code> API<\/a> to make their use safer. Much like the timer_list<\/code> refactoring<\/a> work done earlier, the tasklet<\/code> API is also a potential source of simple function-pointer-and-first-argument controlled exploits via linear heap overwrites. It’s a smaller attack surface since it’s used much less in the kernel, but it is the same weak design, making it a sensible thing to replace. While the use of the tasklet<\/code> API is considered deprecated<\/a> (replaced by threaded IRQs<\/a>), it’s not always a simple mechanical refactoring, so the old API still needs refactoring (since that CAN be done mechanically is most cases).<\/p>\n

x86 FSGSBASE<\/code> implementation<\/strong>
\nSasha Levin, Andy Lutomirski, Chang S. Bae, Andi Kleen, Tony Luck, Thomas Gleixner, and others landed the long-awaited FSGSBASE<\/code> series<\/a>. This provides task switching performance improvements while keeping the kernel safe from modules accidentally (or maliciously) trying to use the features directly (which exposed an unprivileged direct kernel access hole<\/a>).<\/p>\n

filter x86 MSR writes<\/strong>
\nWhile it’s been long understood that writing to CPU Model-Specific Registers (MSRs) from userspace was a bad idea<\/a>, it has been left enabled for things like MSR_IA32_ENERGY_PERF_BIAS<\/code><\/a>. Boris Petkov has decided enough is enough and has now enabled logging and kernel tainting (TAINT_CPU_OUT_OF_SPEC<\/code>) by default and a way to disable MSR writes<\/a> at runtime. (However, since this is controlled by a normal module parameter and the root user can just turn writes back on, I continue to recommend that people build with CONFIG_X86_MSR=n<\/code>.) The expectation is that userspace MSR writes will be entirely removed in future kernels.<\/p>\n

uninitialized_var()<\/code> macro removed<\/strong>
\nI made treewide changes<\/a> to remove the uninitialized_var()<\/code> macro<\/a>, which had been used to silence compiler warnings. The rationale for this macro was weak to begin with (“the compiler is reporting an uninitialized variable that is clearly initialized”) since it was mainly papering over compiler bugs. However, it creates a much more fragile situation in the kernel since now such uses can actually disable automatic stack variable initialization<\/a>, as well as mask legitimate “unused variable” warnings. The proper solution is to just initialize variables the compiler warns about.<\/p>\n

function pointer cast removals<\/strong>
\nOscar Carter has started removing<\/a> function pointer casts<\/a> from the kernel, in an effort to allow the kernel to build with -Wcast-function-type<\/code>. The future use of Control Flow Integrity checking (which does validation of function prototypes matching between the caller and the target) tends not to work well with function casts, so it’d be nice to get rid of these<\/a> before CFI lands.<\/p>\n

flexible array conversions<\/strong>
\nAs part of Gustavo A. R. Silva’s on-going work<\/a> to replace zero-length<\/a> and one-element<\/a> arrays with flexible arrays, he has documented the details of the flexible array conversions<\/a>, and the various helpers<\/a> to be used in kernel code. Every commit gets the kernel closer to building with -Warray-bounds<\/code>, which catches a lot of potential buffer overflows at compile time.<\/p>\n

That’s it for now! Please let me know if you think anything else needs some attention. Next up is Linux v5.10<\/a>.<\/p>\n

© 2021 – 2022, Kees Cook<\/a>. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License<\/a>.
\"CC<\/a> <\/p>\n","protected":false},"excerpt":{"rendered":"

Previously: v5.8 Linux v5.9 was released in October, 2020. Here\u2019s my summary of various security things that I found interesting: seccomp user_notif file descriptor injection Sargun Dhillon added the ability for SECCOMP_RET_USER_NOTIF filters to inject file descriptors into the target process using SECCOMP_IOCTL_NOTIF_ADDFD. This lets container managers fully emulate syscalls like open() and connect(), where […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,20,18,21,6,14,19],"tags":[],"_links":{"self":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1497"}],"collection":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/comments?post=1497"}],"version-history":[{"count":22,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1497\/revisions"}],"predecessor-version":[{"id":1587,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1497\/revisions\/1587"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=1497"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=1497"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=1497"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}