{"id":692,"date":"2013-12-10T15:40:06","date_gmt":"2013-12-10T23:40:06","guid":{"rendered":"http:\/\/www.outflux.net\/blog\/?p=692"},"modified":"2013-12-10T15:40:44","modified_gmt":"2013-12-10T23:40:44","slug":"live-patching-the-kernel","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2013\/12\/10\/live-patching-the-kernel\/","title":{"rendered":"live patching the kernel"},"content":{"rendered":"

A nice set of recent posts have done a great job detailing the remaining ways that a root user can get at kernel memory. Part of this is driven by the ideas behind UEFI Secure Boot, but they come from the same goal: making sure that the root user cannot directly subvert the running kernel. My perspective on this is toward making sure that an attacker who has gained access and then gained root privileges can’t continue to elevate their access and install invisible kernel rootkits.<\/p>\n

An outline for possible attack vectors is spelled out by Matthew Gerrett’s continuing “useful kernel lockdown” patch series<\/a>. The set of attacks was examined by Tyler Borland in “Bypassing modules_disabled security”<\/a>. His post describes each vector in detail, and he ultimately chooses MSR writing as the way to write kernel memory (and shows an example of how to re-enable module loading). One thing not mentioned is that many distros have MSR access as a module, and it’s rarely loaded. If modules_disabled<\/code> is already set, an attacker won’t be able to load the MSR module to begin with. However, the other general-purpose vector, kexec, is still available. To prove out this method, Matthew wrote a proof-of-concept for changing kernel memory via kexec<\/a>.<\/p>\n

Chrome OS is several steps ahead here, since it has hibernation disabled, MSR writing disabled, kexec disabled, modules verified, root filesystem read-only and verified, kernel verified, and firmware verified. But since not all my machines are Chrome OS, I wanted to look at some additional protections against kexec on general-purpose distro kernels that have CONFIG_KEXEC<\/code> enabled, especially those without UEFI Secure Boot and Matthew’s lockdown patch series.<\/p>\n

My goal was to disable kexec without needing to rebuild my entire kernel. For future kernels, I have proposed adding \/proc\/sys\/kernel\/kexec_disabled<\/code><\/a>, a partner to the existing modules_disabled<\/code>, that will one-way toggle kexec off. For existing kernels, things got more ugly.<\/p>\n

What options do I have for patching a running kernel?<\/p>\n

First I looked back at what I’d done in the past with fixing vulnerabilities with systemtap<\/a>. This ends up being a rather heavy-duty way to go about things, since you need all the distro kernel debug symbols, etc. It does work, but has a significant problem: since it uses kprobes, a root user can just turn off the probes, reverting the changes. So that’s not going to work.<\/p>\n

Next I looked at ksplice. The original upstream has gone away<\/a>, but there is still some work being done by Jiri Slaby<\/a>. However, even with his updates which fixed various build problems, there were still more, even when building a 3.2 kernel (Ubuntu 12.04 LTS). So that’s out too, which is too bad, since ksplice does exactly what I want: modifies the running kernel’s functions via a module.<\/p>\n

So, finally, I decided to just do it by hand, and wrote a friendly kernel rootkit. Instead of dealing with flipping page table permissions on the normally-unwritable kernel code memory, I borrowed from PaX’s KERNEXEC feature, and just turn off write protect checking on the CPU briefly to make the changes. The return values for functions on x86_64 are stored in RAX, so I just need to stuff the kexec_load<\/code> syscall with “mov -1, %rax; ret<\/code>” (-1 is EPERM<\/code>):<\/p>\n

\r\n#define pr_fmt(fmt) KBUILD_MODNAME \": \" fmt\r\n\r\n#include <linux\/init.h>\r\n#include <linux\/module.h>\r\n#include <linux\/slab.h>\r\n\r\nstatic unsigned long long_target;\r\nstatic char *target;\r\nmodule_param_named(syscall, long_target, ulong, 0644);\r\nMODULE_PARM_DESC(syscall, \"Address of syscall\");\r\n\r\n\/* mov $-1, %rax; ret *\/\r\nunsigned const char bytes[] = { 0x48, 0xc7, 0xc0, 0xff, 0xff, 0xff, 0xff,\r\n                                0xc3 };\r\nunsigned char *orig;\r\n\r\n\/* Borrowed from PaX KERNEXEC *\/\r\nstatic inline void disable_wp(void)\r\n{\r\n        unsigned long cr0;\r\n\r\n        preempt_disable();\r\n        barrier();\r\n        cr0 = read_cr0();\r\n        cr0 &= ~X86_CR0_WP;\r\n        write_cr0(cr0);\r\n}\r\n\r\nstatic inline void enable_wp(void)\r\n{\r\n        unsigned long cr0;\r\n\r\n        cr0 = read_cr0();\r\n        cr0 |= X86_CR0_WP;\r\n        write_cr0(cr0);\r\n        barrier();\r\n        preempt_enable_no_resched();\r\n}\r\n\r\nstatic int __init syscall_eperm_init(void)\r\n{\r\n        int i;\r\n        target = (char *)long_target;\r\n\r\n        if (target == NULL)\r\n                return -EINVAL;\r\n\r\n        \/* save original *\/\r\n        orig = kmalloc(sizeof(bytes), GFP_KERNEL);\r\n        if (!orig)\r\n                return -ENOMEM;\r\n        for (i = 0; i < sizeof(bytes); i++) {\r\n                orig[i] = target[i];\r\n        }\r\n\r\n        pr_info(\"writing %lu bytes at %p\\n\", sizeof(bytes), target);\r\n\r\n        disable_wp();\r\n        for (i = 0; i < sizeof(bytes); i++) {\r\n                target[i] = bytes[i];\r\n        }\r\n        enable_wp();\r\n\r\n        return 0;\r\n}\r\nmodule_init(syscall_eperm_init);\r\n\r\nstatic void __exit syscall_eperm_exit(void)\r\n{\r\n        int i;\r\n\r\n        pr_info(\"restoring %lu bytes at %p\\n\", sizeof(bytes), target);\r\n\r\n        disable_wp();\r\n        for (i = 0; i < sizeof(bytes); i++) {\r\n                target[i] = orig[i];\r\n        }\r\n        enable_wp();\r\n\r\n        kfree(orig);\r\n}\r\nmodule_exit(syscall_eperm_exit);\r\n\r\nMODULE_LICENSE(\"GPL\");\r\nMODULE_AUTHOR(\"Kees Cook <kees@outflux.net>\");\r\nMODULE_DESCRIPTION(\"makes target syscall always return EPERM\");\r\n<\/pre>\n
If I didn’t want to leave an obvious indication that the kernel had been manipulated, the module could be changed to:<\/p>\n