{"id":987,"date":"2016-12-12T11:05:55","date_gmt":"2016-12-12T19:05:55","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=987"},"modified":"2017-04-24T13:03:52","modified_gmt":"2017-04-24T20:03:52","slug":"security-things-in-linux-v4-9","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2016\/12\/12\/security-things-in-linux-v4-9\/","title":{"rendered":"security things in Linux v4.9"},"content":{"rendered":"

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

Here are a bunch of security things I’m excited about in the newly released Linux v4.9:<\/p>\n

Latent Entropy GCC plugin<\/strong><\/p>\n

Building on her earlier work<\/a> to bring GCC plugin support to the Linux kernel, Emese Revfy ported PaX’s Latent Entropy GCC plugin<\/a> to upstream. This plugin is significantly more complex than the others that have already been ported, and performs extensive instrumentation of functions marked<\/a> with __latent_entropy<\/code>. These functions have their branches and loops adjusted to mix random values (selected at build time) into a global entropy gathering variable. Since the branch and loop ordering is very specific to boot conditions, CPU quirks, memory layout, etc, this provides some additional uncertainty to the kernel’s entropy pool. Since the entropy actually gathered is hard to measure, no entropy is “credited”, but rather used to mix the existing pool further. Probably the best place to enable this plugin is on small devices without other strong sources of entropy.<\/p>\n

vmapped kernel stack and thread_info relocation on x86<\/strong><\/p>\n

Normally, kernel stacks are mapped together in memory. This meant that attackers could use forms of stack exhaustion (or stack buffer overflows) to reach past the end of a stack and start writing over another process’s stack. This is bad, and one way to stop it is to provide guard pages between stacks, which is provided by vmalloc<\/code>ed memory. Andy Lutomirski did a bunch of work to move to vmapped kernel stack via CONFIG_VMAP_STACK<\/code><\/a> on x86_64. Now when writing past the end of the stack, the kernel will immediately fault instead of just continuing to blindly write.<\/p>\n

Related to this, the kernel was storing thread_info<\/code> (which contained sensitive values like addr_limit<\/code>) at the bottom of the kernel stack, which was an easy target for attackers to hit. Between a combination of explicitly moving targets out of thread_info<\/code><\/a>, removing needless fields, and entirely moving thread_info<\/code> off the stack<\/a>, Andy Lutomirski and Linus Torvalds created CONFIG_THREAD_INFO_IN_TASK<\/code> for x86.<\/p>\n

CONFIG_DEBUG_RODATA mandatory on arm64<\/strong><\/p>\n

As recently done for x86<\/a>, Mark Rutland made CONFIG_DEBUG_RODATA mandatory on arm64<\/a>. This feature controls whether the kernel enforces proper memory protections on its own memory regions (code memory is executable and read-only, read-only data is actually read-only and non-executable, and writable data is non-executable). This protection is a fundamental security primitive for kernel self-protection, so there’s no reason to make the protection optional.<\/p>\n

random_page()<\/code> cleanup<\/strong><\/p>\n

Cleaning up the code around the userspace ASLR implementations makes them easier to reason about. This has been happening for things like the recent consolidation on arch_mmap_rnd()<\/code> for ET_DYN<\/code><\/a> and during the addition of the entropy sysctl<\/a>. Both uncovered some awkward uses of get_random_int()<\/code> (or similar) in and around arch_mmap_rnd()<\/code> (which is used for mmap<\/code> (and therefore shared library) and PIE ASLR), as well as in randomize_stack_top()<\/code> (which is used for stack ASLR). Jason Cooper cleaned things up further by doing away with randomize_range()<\/code> entirely and replacing it with the saner random_page()<\/code><\/a>, making the per-architecture arch_randomize_brk()<\/code> (responsible for brk<\/code> ASLR) much easier to understand.<\/p>\n

Edit: missed this next feature when I first posted!<\/em><\/p>\n

User namespace restrictions<\/strong><\/p>\n

Eric Biederman landed a sysctl<\/a> to control how many user namespaces can be created (on a per-user and per-namespace basis) via \/proc\/sys\/user\/max_user_namespaces<\/code>. The ability to limit access to user namespaces has been desired for a while<\/a>, since a large amount of attack surface gets exposed from within a user namespace, due to it allowing various interfaces to operate within the namespace that were originally limited to the true root user before. A system can now disable user namespaces by writing 0<\/code> to the sysctl.<\/p>\n

That’s it for now! Let me know if there are other fun things to call attention to in v4.10<\/a>.<\/p>\n

© 2016 – 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.8. Here are a bunch of security things I’m excited about in the newly released Linux v4.9: Latent Entropy GCC plugin Building on her earlier work to bring GCC plugin support to the Linux kernel, Emese Revfy ported PaX’s Latent Entropy GCC plugin to upstream. This plugin is significantly more complex than the others […]<\/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\/987"}],"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=987"}],"version-history":[{"count":8,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/987\/revisions"}],"predecessor-version":[{"id":1015,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/987\/revisions\/1015"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=987"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=987"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=987"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}