{"id":1441,"date":"2020-09-21T16:32:16","date_gmt":"2020-09-21T23:32:16","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=1441"},"modified":"2022-04-04T16:32:36","modified_gmt":"2022-04-04T23:32:36","slug":"security-things-in-linux-v5-7","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2020\/09\/21\/security-things-in-linux-v5-7\/","title":{"rendered":"security things in Linux v5.7"},"content":{"rendered":"

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

Linux v5.7 was released at the end of May<\/a>. Here\u2019s my summary of various security things that caught my attention:<\/p>\n

arm64 kernel pointer authentication<\/strong>
\nWhile the ARMv8.3 CPU “Pointer Authentication” (PAC) feature landed for userspace already<\/a>, Kristina Martsenko has now landed PAC support in kernel mode<\/a>. The current implementation uses PACIASP<\/code> which protects the saved stack pointer, similar to the existing CONFIG_STACKPROTECTOR<\/code> feature, only faster. This also paves the way to sign and check pointers stored in the heap, as a way to defeat function pointer overwrites in those memory regions too. Since the behavior is different from the traditional stack protector, Amit Daniel Kachhap added an LKDTM test for PAC<\/a> as well.<\/p>\n

BPF LSM<\/strong>
\nThe kernel’s Linux Security Module (LSM) API provide a way to write security modules that have traditionally implemented various Mandatory Access Control (MAC) systems like SELinux, AppArmor, etc. The LSM hooks are numerous and no one LSM uses them all, as some hooks are much more specialized (like those used by IMA, Yama, LoadPin, etc). There was not, however, any way to externally attach to these hooks (not even through a regular loadable kernel module) nor build fully dynamic security policy, until KP Singh landed the API for building LSM policy using BPF<\/a>. With CONFIG_BPF_LSM=y<\/code>, it is possible (for a privileged process) to write kernel LSM hooks in BPF, allowing for totally custom security policy (and reporting).<\/p>\n

execve()<\/code> deadlock refactoring<\/strong>
\nThere have been a number of long-standing races in the kernel’s process launching code where ptrace could deadlock. Fixing these has been attempted several times over the last many years, but Eric W. Biederman and Ernd Edlinger decided to dive in, and successfully landed the a series of refactorings, splitting up the problematic locking<\/a> and refactoring their uses to remove the deadlocks<\/a>. While he was at it, Eric also extended the exec_id<\/code> counter to 64 bits<\/a> to avoid the possibility of the counter wrapping and allowing an attacker to send arbitrary signals to processes they normally shouldn’t be able to.<\/p>\n

slub freelist obfuscation improvements<\/strong>
\nAfter Silvio Cesare observed some weaknesses in the implementation of CONFIG_SLAB_FREELIST_HARDENED<\/code>‘s freelist pointer content obfuscation, I improved their bit diffusion<\/a>, which makes attacks require significantly more memory content exposures to defeat the obfuscation. As part of the conversation, Vitaly Nikolenko pointed out that the freelist pointer’s location<\/i> made it relatively easy to target too (for either disclosures or overwrites), so I moved it away from the edge of the slab<\/a>, making it harder to reach through small-sized overflows (which usually target the freelist pointer). As it turns out, there were a few assumptions in the kernel about the location of the freelist pointer, which had to also get cleaned<\/a> up<\/a>.<\/p>\n

RISCV strict kernel memory protections<\/strong>
\nZong Li implemented STRICT_KERNEL_RWX<\/code> support for RISCV<\/a>. And to validate the results, following v5.6’s generic page table dumping work<\/a>, he landed the RISCV page dumping code<\/a>. This means it’s much easier to examine the kernel’s page table layout when running a debug kernel (built with PTDUMP_DEBUGFS<\/code>), visible in \/sys\/kernel\/debug\/kernel_page_tables<\/code>.<\/p>\n

array index bounds checking<\/strong>
\nThis is a pretty large area of work that touches a lot of overlapping elements (and history) in the Linux kernel. The short version is: C is bad at noticing when it uses an array index beyond the bounds of the declared array, and we need to fix that. For example, don’t do this:<\/p>\n

\r\nint foo[5];\r\n...\r\nfoo[8] = bar;\r\n<\/pre>\n
The long version gets complicated by the evolution of “flexible array” structure members<\/a>, so we’ll pause for a moment and skim the surface of this topic. While things like CONFIG_FORTIFY_SOURCE<\/code> try to catch these kinds of cases in the memcpy()<\/code> and strcpy()<\/code> family of functions, it doesn’t catch it in open-coded array indexing, as seen in the code above. GCC has a warning (-Warray-bounds<\/code>) for these cases, but it was disabled by Linus<\/a> because of all the false positives seen due to “fake” flexible array members. Before flexible arrays were standardized, GNU C supported “zero sized” array members. And before that, C code would use a 1-element array. These were all designed so that some structure could be the “header” in front of some data blob that could be addressable through the last structure member:<\/p>\n
\r\n\/* 1-element array *\/\r\nstruct foo {\r\n    ...\r\n    char contents[1];\r\n};\r\n\r\n\/* GNU C extension: 0-element array *\/\r\nstruct foo {\r\n    ...\r\n    char contents[0];\r\n};\r\n\r\n\/* C standard: flexible array *\/\r\nstruct foo {\r\n    ...\r\n    char contents[];\r\n};\r\n\r\ninstance = kmalloc(sizeof(struct foo) + content_size);\r\n<\/pre>\n
Converting all the zero- and one-element array members to flexible arrays is one of Gustavo A. R. Silva’s goals, and hundreds of these changes started landing<\/a>. Once fixed, -Warray-bounds<\/code> can be re-enabled. Much more detail can be found in the kernel’s deprecation<\/a> docs.<\/p>\n
However, that will only catch the “visible at compile time” cases. For runtime checking, the Undefined Behavior Sanitizer has an option for adding runtime array bounds checking for catching things like this where the compiler cannot perform a static analysis of the index values:<\/p>\n
\r\nint foo[5];\r\n...\r\nfor (i = 0; i < some_argument; i++) {\r\n    ...\r\n    foo[i] = bar;\r\n    ...\r\n}\r\n<\/pre>\n
It was, however, not separate (via kernel Kconfig) until Elena Petrova and I split it out into CONFIG_UBSAN_BOUNDS<\/code><\/a>, which is fast enough for production kernel use. With this enabled, it's now possible to instrument the kernel to catch these conditions, which seem to come up with some regularity in Wi-Fi and Bluetooth drivers for some reason. Since UBSAN (and the other Sanitizers) only WARN()<\/code> by default, system owners need to set panic_on_warn=1<\/code> too if they want to defend against attacks targeting these kinds of flaws. Because of this, and to avoid bloating the kernel image with all the warning messages, I introduced CONFIG_UBSAN_TRAP<\/code><\/a> which effectively turns these conditions into a BUG()<\/code> without needing additional sysctl settings.<\/p>\n
Fixing \"additive\" snprintf()<\/code> usage<\/strong>
\nA common idiom in C for building up strings is to use sprintf()<\/code>'s return value to increment a pointer into a string, and build a string with more sprintf()<\/code> calls:<\/p>\n
\r\n\/* safe if strlen(foo) + 1 < sizeof(string) *\/\r\nwrote  = sprintf(string, \"Foo: %s\\n\", foo);\r\n\/* overflows if strlen(foo) + strlen(bar) > sizeof(string) *\/\r\nwrote += sprintf(string + wrote, \"Bar: %s\\n\", bar);\r\n\/* writing way beyond the end of \"string\" now ... *\/\r\nwrote += sprintf(string + wrote, \"Baz: %s\\n\", baz);\r\n<\/pre>\n
The risk is that if these calls eventually walk off the end of the string<\/code> buffer, it will start writing into other memory and create some bad situations. Switching these to snprintf()<\/code> does not, however, make anything safer, since snprintf()<\/code> returns how much it would<\/i> have written:<\/p>\n
\r\n\/* safe, assuming available <= sizeof(string), and for this example\r\n * assume strlen(foo) < sizeof(string) *\/\r\nwrote  = snprintf(string, available, \"Foo: %s\\n\", foo);\r\n\/* if (strlen(bar) > available - wrote), this is still safe since the\r\n * write into \"string\" will be truncated, but now \"wrote\" has been\r\n * incremented by how much snprintf() *would* have written, so \"wrote\"\r\n * is now larger than \"available\". *\/\r\nwrote += snprintf(string + wrote, available - wrote, \"Bar: %s\\n\", bar);\r\n\/* string + wrote is beyond the end of string, and availabe - wrote wraps\r\n * around to a giant positive value, making the write effectively \r\n * unbounded. *\/\r\nwrote += snprintf(string + wrote, available - wrote, \"Baz: %s\\n\", baz);\r\n<\/pre>\n
So while the first overflowing call would be safe, the next one would be targeting beyond the end of the array and the size calculation will have wrapped around to a giant limit. Replacing this idiom with scnprintf()<\/code> solves the issue because it only reports what was actually<\/i> written. To this end, Takashi Iwai has been landing a bunch scnprintf() fixes<\/a>.<\/p>\n
That's it for now! Let me know if there is anything else you think I should mention here. Next up: Linux v5.8<\/a>.<\/p>\n
© 2020 - 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.6 Linux v5.7 was released at the end of May. Here\u2019s my summary of various security things that caught my attention: arm64 kernel pointer authentication While the ARMv8.3 CPU “Pointer Authentication” (PAC) feature landed for userspace already, Kristina Martsenko has now landed PAC support in kernel mode. The current implementation uses PACIASP which protects […]<\/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\/1441"}],"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=1441"}],"version-history":[{"count":31,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1441\/revisions"}],"predecessor-version":[{"id":1574,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1441\/revisions\/1574"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=1441"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=1441"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=1441"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}