Date: Tue, 19 Feb 2019 22:18:51 +0100 From: Solar Designer <solar@...nwall.com> To: announce@...ts.openwall.com, lkrg-users@...ts.openwall.com Subject: [openwall-announce] LKRG 0.6 Hi, We'd like to announce Linux Kernel Runtime Guard (LKRG) version 0.6: https://www.openwall.com/lkrg/ The following changes have been made between LKRG 0.5 and 0.6: *) [CI] Protect SMEP bit in CR4 and WP bit in CR0 on x86 architecture *) [CI] Reimplement *_JUMP_LABEL support: simpler and needs a lot less memory *) [CI] Propagate errors when kzalloc() fails *) [ED] Introduce pCFI mitigation (poor man's Control Flow Integrity) against unintended invocation of a few kernel functions especially useful in exploits *) [ED] Lock down the usermodehelper interface with a whitelist of programs *) [ED] Fix false positive on seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, ...) failing, where we must revert all threads' settings but did not (we do now) *) [ED] Freeze all user mode processes during Exploit Detection initialization to avoid false positives *) [ED] Minor change in how SIGKILL is delivered to the corrupted task *) Fix build error on Linux 4.17+ without CONFIG_ARCH_HAS_SYSCALL_WRAPPER *) Add LKRG early boot systemd unit file. (Similar optional functionality for other init systems may be added later. Contributions are welcome.) *) Add install/uninstall make targets, which deploy/remove the systemd service Legend: [CI] - Code Integrity [ED] - Exploit Detection Like before, this release is mostly due to work by Adam 'pi3' Zabrocki. I mostly contributed to discussions on its functionality. We realize that introduction of systemd support into a security project is especially ironic at a time when yet another systemd vulnerability has just been made public: https://www.openwall.com/lists/oss-security/2019/02/18/3 However, this is actually consistent: LKRG is for poor man's hardening of systems that run presumably vulnerable kernels. They may, and these days usually do, take the risk of running systemd as well. That said, we don't in any way favor systemd over other init systems, and would gladly add support for those as well if there's demand or especially if we receive such contributions. In related news, as discussed on the lkrg-users mailing list: Shortly after we released LKRG 0.5, Ilya Matveychikov enhanced Andrey Konovalov's exploit for CVE-2017-1000112 to bypass LKRG in two different but similar ways on a specific version of Ubuntu: https://www.openwall.com/lists/lkrg-users/2018/11/16/2 https://www.openwall.com/lists/lkrg-users/2018/11/17/4 These two are the very first (and so far the only) LKRG exploit detection bypasses we're aware of. We're not too concerned since LKRG is bypassable by design. Rather, we're pleased to see specific LKRG bypasses so that their complexity and generality can be evaluated. In this case, Andrey's exploit listed 12 hard-coded ROP gadget offsets per target kernel build, and Ilya's LKRG bypasses added 1 to 3 more. On one hand, this shows that the exploit was generic enough to allow for such extension. On the other, it shows that it was (had to be? or not?) specialized for a target kernel build even further. The addition of pCFI and lock down of usermodehelper in this release are prompted by the bypasses Ilya had demonstrated. This should be viewed as an experiment. We're undecided on whether we'll continue to enhance pCFI or maybe introduce other mitigations in response to future bypasses, or on the contrary remove these mitigations for the sake of simplicity (since, once again, LKRG is bypassable by design anyway). We also had reports of kzalloc() failures from Pawel Krawczyk and Diego M. Vadell on lkrg-users - thanks! The reimplemented *_JUMP_LABEL support should help avoid these, and error reporting should now be better should there be a memory allocation failure anyway. As I understand, the subtle seccomp error handling fix is also due to a report by Pawel. We also became aware of a blog post by Leszek Mis on LKRG successfully detecting the Suterusu kernel rootkit even when that rootkit is loaded into the kernel before LKRG: https://www.defensive-security.com/blog/playing-with-linux-kernel-runtime-guard-lkrg LKRG wasn't meant to help in that scenario: pre-compromised system, rootkit loaded by legitimate means (LKM, as root). Yet LKRG managed to detect attempted interaction with the rootkit anyway. As usual, we welcome any feedback on lkrg-users. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.