{"id":1028,"date":"2017-07-10T01:24:23","date_gmt":"2017-07-10T08:24:23","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=1028"},"modified":"2017-11-20T11:15:48","modified_gmt":"2017-11-20T19:15:48","slug":"security-things-in-linux-v4-12","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2017\/07\/10\/security-things-in-linux-v4-12\/","title":{"rendered":"security things in Linux v4.12"},"content":{"rendered":"

Previously: v4.11<\/a>.<\/p>\n

Here\u2019s a quick summary of some of the interesting security things in last week\u2019s v4.12 release of the Linux kernel:<\/p>\n

x86 read-only and fixed-location GDT<\/strong>
\nWith kernel memory base randomization<\/a>, it was stil possible to figure out the per-cpu base address via the “sgdt” instruction, since it would reveal the per-cpu GDT location. To solve this, Thomas Garnier moved the GDT to a fixed location<\/a>. And to solve the risk of an attacker targeting the GDT directly with a kernel bug, he also made it read-only<\/a>.<\/p>\n

usercopy consolidation<\/strong>
\nAfter hardened usercopy<\/a> landed, Al Viro decided to take a closer look at all the usercopy routines and then consolidated the per-architecture uaccess code<\/a> into a single implementation. The per-architecture code was functionally very similar to each other, so it made sense to remove the redundancy. In the process, he uncovered a number of unhandled corner cases in various architectures (that got fixed by the consolidation), and made hardened usercopy available on all remaining architectures<\/a>.<\/p>\n

ASLR entropy sysctl on PowerPC<\/strong>
\nContinuing to expand architecture support for the ASLR entropy sysctl<\/a>, Michael Ellerman implemented the calculations needed for PowerPC<\/a>. This lets userspace choose to crank up the entropy used for memory layouts.<\/p>\n

LSM structures read-only<\/strong>
\nJames Morris used __ro_after_init<\/code><\/a> to make the LSM structures read-only after boot<\/a>. This removes them as a desirable target for attackers. Since the hooks are called from all kinds of places in the kernel this was a favorite method for attackers to use to hijack execution of the kernel. (A similar target used to be the system call table, but that has long since been made read-only.) Be wary that CONFIG_SECURITY_SELINUX_DISABLE<\/code> removes this protection, so make sure that config stays disabled.<\/p>\n

KASLR enabled by default on x86<\/strong>
\nWith many distros already enabling KASLR<\/a> on x86 with CONFIG_RANDOMIZE_BASE<\/code> and CONFIG_RANDOMIZE_MEMORY<\/code>, Ingo Molnar felt the feature was mature enough to be enabled by default<\/a>.<\/p>\n

Expand stack canary to 64 bits on 64-bit systems<\/strong>
\nThe stack canary values used by CONFIG_CC_STACKPROTECTOR<\/code><\/a> is most powerful on x86 since it is different per task. (Other architectures run with a single canary for all tasks.) While the first canary chosen on x86 (and other architectures) was a full unsigned long<\/code>, the subsequent canaries chosen per-task for x86 were being truncated to 32-bits. Daniel Micay fixed this<\/a> so now x86 (and future architectures that gain per-task canary support) have significantly increased entropy for stack-protector.<\/p>\n

Expanded stack\/heap gap<\/strong>
\nHugh Dickens, with input from many other folks, improved the kernel’s mitigation<\/a> against having the stack and heap crash into each other. This is a stop-gap measure to help defend against the Stack Clash<\/a> attacks. Additional hardening needs to come from the compiler to produce “stack probes” when doing large stack expansions. Any Variable Length Arrays on the stack or alloca()<\/code> usage needs to have machine code generated to touch each page of memory within those areas to let the kernel know that the stack is expanding, but with single-page granularity.<\/p>\n

That\u2019s it for now; please let me know if I missed anything. The v4.13<\/a> merge window is open!<\/p>\n

Edit: Brad Spengler pointed out that I failed to mention the CONFIG_SECURITY_SELINUX_DISABLE<\/code> issue with read-only LSM structures. This has been added now.<\/p>\n

© 2017, 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: v4.11. Here\u2019s a quick summary of some of the interesting security things in last week\u2019s v4.12 release of the Linux kernel: x86 read-only and fixed-location GDT With kernel memory base randomization, it was stil possible to figure out the per-cpu base address via the “sgdt” instruction, since it would reveal the per-cpu GDT location. […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,18,21,6,14,19],"tags":[],"_links":{"self":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1028"}],"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=1028"}],"version-history":[{"count":11,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1028\/revisions"}],"predecessor-version":[{"id":1091,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1028\/revisions\/1091"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=1028"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=1028"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=1028"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}