{"id":896,"date":"2016-09-27T14:47:08","date_gmt":"2016-09-27T22:47:08","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=896"},"modified":"2016-10-05T21:31:52","modified_gmt":"2016-10-06T04:31:52","slug":"security-things-in-linux-v4-4","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2016\/09\/27\/security-things-in-linux-v4-4\/","title":{"rendered":"security things in Linux v4.4"},"content":{"rendered":"<p>Previously: <a href=\"\/blog\/archives\/2016\/09\/26\/security-things-in-linux-v4-3\/\">v4.3<\/a>. Continuing with interesting security things in the Linux kernel, here&#8217;s v4.4. As before, if you think there&#8217;s stuff I missed that should get some attention, please let me know.<\/p>\n<p><strong>seccomp Checkpoint\/Restore-In-Userspace<\/strong><\/p>\n<p>Tycho Andersen added a way to extract and restore seccomp filters from running processes via <a href=\"https:\/\/git.kernel.org\/linus\/f8e529ed941ba2bbcbf310b575d968159ce7e895\">PTRACE_SECCOMP_GET_FILTER<\/a> under CONFIG_CHECKPOINT_RESTORE. This is a continuation of his work (that I failed to mention in my prior post) from v4.3, which introduced a way to suspend and resume seccomp filters. As I mentioned at the time (and for which he continues to quote me) <a href=\"http:\/\/lkml.iu.edu\/hypermail\/linux\/kernel\/1506.0\/03354.html\">&#8220;this feature gives me the creeps.&#8221;<\/a> :)<\/p>\n<p><strong>x86 W^X detection<\/strong><\/p>\n<p>Stephen Smalley noticed that there was still a range of kernel memory (just past the end of the kernel code itself) that was incorrectly marked writable and executable, defeating the point of CONFIG_DEBUG_RODATA which seeks to eliminate these kinds of memory ranges. He <a href=\"https:\/\/git.kernel.org\/linus\/ab76f7b4ab2397ffdd2f1eb07c55697d19991d10\">corrected this<\/a> in v4.3 and added <a href=\"https:\/\/git.kernel.org\/linus\/e1a58320a38dfa72be48a0f1a3a92273663ba6db\">CONFIG_DEBUG_WX<\/a> in v4.4 which performs a scan of memory at boot time and yells loudly if unexpected memory protection are found. To nobody&#8217;s delight, it was shortly discovered the UEFI leaves chunks of memory in this state too, which posed an ugly-to-solve problem (which Matt Fleming <a href=\"https:\/\/git.kernel.org\/linus\/67a9108ed4313b85a9c53406d80dc1ae3f8c3e36\">addressed in v4.6<\/a>).<\/p>\n<p><strong>x86_64 vsyscall CONFIG<\/strong><\/p>\n<p>I introduced a way to control the mode of the x86_64 vsyscall with a build-time CONFIG selection, though the choice I really care about is <a href=\"https:\/\/git.kernel.org\/linus\/3dc33bd30f3e1c1bcaaafa3482737694debf0f0b\">CONFIG_LEGACY_VSYSCALL_NONE<\/a>, to force the vsyscall memory region off by default. The vsyscall memory region was always mapped into process memory at a fixed location, and it originally posed a security risk as a ROP gadget execution target. The vsyscall emulation mode was added to mitigate the problem, but it still left fixed-position static memory content in all processes, which could <a href=\"https:\/\/googleprojectzero.blogspot.com\/2015\/08\/three-bypasses-and-fix-for-one-of.html\">still pose a security risk<\/a>. The good news is that glibc since version 2.15 doesn&#8217;t need vsyscall at all, so it can just be removed entirely. Any kernel built this way that discovered they needed to support a pre-2.15 glibc could still re-enable it at the kernel command line with &#8220;vsyscall=emulate&#8221;.<\/p>\n<p>That&#8217;s it for v4.4. Tune in tomorrow for <a href=\"\/blog\/archives\/2016\/09\/28\/security-things-in-linux-v4-5\/\">v4.5<\/a>!<\/p>\n<p style='text-align:left'>&copy; 2016, <a href=\"https:\/\/outflux.net\/blog\/\">Kees Cook<\/a>. This work is licensed under a <a rel=\"license\" href=\"http:\/\/creativecommons.org\/licenses\/by-sa\/4.0\/\">Creative Commons Attribution-ShareAlike 4.0 License<\/a>.<br \/><a rel=\"license\" href=\"http:\/\/creativecommons.org\/licenses\/by-sa\/4.0\/\"><img decoding=\"async\" alt=\"CC BY-SA 4.0\" style=\"border-width:0\" src=\"https:\/\/i.creativecommons.org\/l\/by-sa\/4.0\/88x31.png\" \/><\/a> <\/p>\n","protected":false},"excerpt":{"rendered":"<p>Previously: v4.3. Continuing with interesting security things in the Linux kernel, here&#8217;s v4.4. As before, if you think there&#8217;s stuff I missed that should get some attention, please let me know. seccomp Checkpoint\/Restore-In-Userspace Tycho Andersen added a way to extract and restore seccomp filters from running processes via PTRACE_SECCOMP_GET_FILTER under CONFIG_CHECKPOINT_RESTORE. This is a continuation [&hellip;]<\/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\/896"}],"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=896"}],"version-history":[{"count":15,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/896\/revisions"}],"predecessor-version":[{"id":957,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/896\/revisions\/957"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=896"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=896"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=896"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}