{"id":1075,"date":"2017-11-14T21:23:50","date_gmt":"2017-11-15T05:23:50","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=1075"},"modified":"2019-07-29T10:41:14","modified_gmt":"2019-07-29T17:41:14","slug":"security-things-in-linux-v4-14","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2017\/11\/14\/security-things-in-linux-v4-14\/","title":{"rendered":"security things in Linux v4.14"},"content":{"rendered":"

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

Linux kernel v4.14 was released<\/a> this last Sunday, and there’s a bunch of security things I think are interesting:<\/p>\n

vmapped kernel stack on arm64<\/strong>
\nSimilar to the same feature on x86<\/a>, Mark Rutland and Ard Biesheuvel implemented<\/a> CONFIG_VMAP_STACK<\/code> for arm64, which moves the kernel stack to an isolated and guard-paged vmap area. With traditional stacks, there were two major risks when exhausting the stack: overwriting the thread_info<\/code> structure (which contained the addr_limit<\/code> field which is checked during copy_to\/from_user()<\/code>), and overwriting neighboring stacks (or other things allocated next to the stack). While arm64 previously moved its thread_info off the stack<\/a> to deal with the former issue, this vmap change adds the last bit of protection by nature of the vmap guard pages. If the kernel tries to write past the end of the stack, it will hit the guard page and fault. (Testing for this is now possible via LKDTM’s STACK_GUARD_PAGE_LEADING\/TRAILING<\/code> tests<\/a>.)<\/p>\n

One aspect of the guard page protection that will need further attention (on all architectures) is that if the stack grew because of a giant Variable Length Array on the stack (effectively an implicit alloca()<\/code> call), it might be possible to jump over the guard page entirely (as seen in the userspace Stack Clash<\/a> attacks). Thankfully the use of VLAs is rare in the kernel. In the future, hopefully we’ll see the addition of PaX\/grsecurity’s STACKLEAK<\/a> plugin which, in addition to its primary purpose of clearing the kernel stack on return to userspace, makes sure stack expansion cannot skip over guard pages. This “stack probing” ability will likely also become directly available from the compiler<\/a> as well.<\/p>\n

set_fs()<\/code> balance checking<\/strong>
\nRelated to the addr_limit<\/code> field mentioned above, another class of bug is finding a way to force the kernel into accidentally leaving addr_limit<\/code> open to kernel memory through an unbalanced call to set_fs()<\/code>. In some areas of the kernel, in order to reuse userspace routines (usually VFS or compat related), code will do something like: set_fs(KERNEL_DS); ...some code here...; set_fs(USER_DS);<\/code>. When the USER_DS<\/code> call goes missing (usually due to a buggy error path<\/a> or exception<\/a>), subsequent system calls can suddenly start writing into kernel memory via copy_to_user<\/code> (where the “to user” really means “within the addr_limit<\/code> range”).<\/p>\n

Thomas Garnier implemented USER_DS checking<\/a> at syscall exit time for x86, arm<\/a>, and arm64<\/a> (with a small fix<\/a>). This means that a broken set_fs()<\/code> setting will not extend beyond the buggy syscall that fails to set it back to USER_DS<\/code>. Additionally, as part of the discussion on the best way to deal with this feature, Christoph Hellwig and Al Viro (and others) have been making extensive changes<\/a> to avoid the need for set_fs()<\/code> being used at all, which should greatly reduce the number of places where it might be possible to introduce such a bug in the future.<\/p>\n

SLUB freelist hardening<\/strong>
\nA common class of heap attacks is overwriting the freelist pointers<\/a> stored inline in the unallocated SLUB cache objects. PaX\/grsecurity developed an inexpensive defense that XORs the freelist pointer with a global random value (and the storage address). Daniel Micay improved on this by using a per-cache random value, and I refactored the code a bit more. The resulting feature<\/a>, enabled with CONFIG_SLAB_FREELIST_HARDENED<\/code>, makes freelist pointer overwrites very hard to exploit unless an attacker has found a way to expose both the random value and the pointer location. This should render blind heap overflow bugs much more difficult to exploit.<\/p>\n

Additionally, Alexander Popov implemented a simple double-free defense<\/a>, similar to the “fasttop”<\/a> check in the GNU C library, which will catch sequential free()<\/code>s of the same pointer. (And has already uncovered a bug<\/a>.)<\/p>\n

Future work would be to provide similar metadata protections to the SLAB allocator (though SLAB doesn’t store its freelist within the individual unused objects<\/a>, so it has a different set of exposures compared to SLUB).<\/p>\n

setuid-exec stack limitation<\/strong>
\nContinuing the various additional defenses to protect against future problems related to userspace memory layout manipulation (as shown most recently in the Stack Clash<\/a> attacks), I implemented an 8MiB stack limit<\/a> for privileged (i.e. setuid) execs, inspired by a similar protection in grsecurity, after reworking the secureexec handling by LSMs. This complements the unconditional limit to the size of exec arguments<\/a> that landed in v4.13.<\/p>\n

randstruct automatic struct selection<\/strong>
\nWhile the bulk of the port of the randstruct gcc plugin<\/a> from grsecurity landed in v4.13, the last of the work needed to enable automatic struct selection<\/a> landed in v4.14. This means that the coverage of randomized structures, via CONFIG_GCC_PLUGIN_RANDSTRUCT<\/code>, now includes one of the major targets of exploits: function pointer structures. Without knowing the build-randomized location of a callback pointer an attacker needs to overwrite in a structure, exploits become much less reliable.<\/p>\n

structleak passed-by-reference variable initialization<\/strong>
\nArd Biesheuvel enhanced the structleak gcc plugin<\/a> to initialize all variables on the stack that are passed by reference when built with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL<\/code>. Normally the compiler will yell if a variable is used before being initialized, but it silences this warning if the variable’s address is passed into a function call first, as it has no way to tell if the function did actually initialize the contents. So the plugin now zero-initializes such variables (if they hadn’t already been initialized) before the function call that takes their address. Enabling this feature has a small performance impact, but solves many stack content exposure flaws. (In fact at least one such flaw<\/a> reported during the v4.15 development cycle was mitigated by this plugin.)<\/p>\n

improved boot entropy<\/strong>
\nLaura Abbott and Daniel Micay improved early boot entropy available to the stack protector by both moving the stack protector setup later in the boot<\/a>, and including the kernel command line in boot entropy collection<\/a> (since with some devices it changes on each boot).<\/p>\n

eBPF JIT for 32-bit ARM<\/strong>
\nThe ARM BPF JIT had been around a while, but it didn’t support eBPF (and, as a result, did not provide constant value blinding<\/a>, which meant it was exposed to being used by an attacker to build arbitrary machine code with BPF constant values). Shubham Bansal spent a bunch of time building a full eBPF JIT for 32-bit ARM<\/a> which both speeds up eBPF and brings it up to date on JIT exploit defenses in the kernel.<\/p>\n

seccomp improvements<\/strong>
\nTyler Hicks addressed a long-standing deficiency in how seccomp could log action results. In addition to creating a way to mark a specific seccomp filter<\/a> as needing to be logged with SECCOMP_FILTER_FLAG_LOG<\/code>, he added a new action result, SECCOMP_RET_LOG<\/code><\/a>. With these changes in place, it should be much easier for developers to inspect the results of seccomp filters, and for process launchers to generate logs for their child processes operating under a seccomp filter.<\/p>\n

Additionally, I finally found a way to implement an often-requested feature for seccomp, which was to kill an entire process instead of just the offending thread. This was done by creating the SECCOMP_RET_ACTION_FULL<\/code> mask (n\u00c3\u00a9e SECCOMP_RET_ACTION<\/code>) and implementing SECCOMP_RET_KILL_PROCESS<\/code><\/a>.<\/p>\n

That\u00e2\u20ac\u2122s it for now; please let me know if I missed anything. The v4.15<\/a> merge window is now open!<\/p>\n","protected":false},"excerpt":{"rendered":"

Previously: v4.13. Linux kernel v4.14 was released this last Sunday, and there’s a bunch of security things I think are interesting: vmapped kernel stack on arm64 Similar to the same feature on x86, Mark Rutland and Ard Biesheuvel implemented CONFIG_VMAP_STACK for arm64, which moves the kernel stack to an isolated and guard-paged vmap area. With […]<\/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\/1075"}],"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=1075"}],"version-history":[{"count":16,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1075\/revisions"}],"predecessor-version":[{"id":1339,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1075\/revisions\/1339"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=1075"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=1075"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=1075"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}