|
Message-ID: <20190721144021.GA876@openwall.com> Date: Sun, 21 Jul 2019 16:40:21 +0200 From: Solar Designer <solar@...nwall.com> To: announce@...ts.openwall.com, lkrg-users@...ts.openwall.com Subject: [openwall-announce] LKRG 0.7 Hi, We'd like to announce Linux Kernel Runtime Guard (LKRG) version 0.7: https://www.openwall.com/lkrg/ The following changes have been made between LKRG 0.6 and 0.7: *) Refactor LKRG code to support multiple CPU architectures *) Add experimental support for ARM64 *) Add experimental support for grsecurity kernels (with some limitations) *) Add support for kernels 5.1 and 5.2 (and hopefully beyond) *) Add support for kernels without enabled CONFIG_DYNAMIC_DEBUG *) Add support for kernels without enabled CONFIG_ACPI *) Add support for kernels without enabled CONFIG_STACKTRACE *) Add support for kernels with enabled CONFIG_STATIC_USERMODEHELPER *) [CI] Fix race condition with *_JUMP_LABEL engine resulting in potential deadlock when LKRG is initialized in parallel with other heavy kernel module (un)loading events *) [CI] Re-enable self-hashing *) [ED] Change the logic how LKRG tracks a newly created task in the system *) [ED] Rewrite internal logic how LKRG synchronizes with the task's resources *) [ED] Filter our kernel threads and system-init process when validation is performed bypassing threads iteration *) [ED] Disable IRQ in most cases when LKRG's PIDs database lock is taken. Otherwise, we could have potential race and deadlock with kprobe engine itself, and SoftIRQs could deadlock with LKRG's pCFI. *) [ED] Fix potential FP during LKRG unloading procedure and add memory barrier *) [ED] Fix logic for *init_module/delete_module for kernels with CONFIG_ARCH_HAS_SYSCALL_WRAPPER *) [ED] Fix FP (race condition) in pCFI in glitching scenario during process update, and add memory barrier *) [ED] Fix potential glitch in pCFI *) [ED] Add support for OverlayFS (which is commonly used by Docker) *) [ED] Whitelist Ubuntu Apport (thanks to Pawel Krawczyk) *) [ED] Enforce stack pointer validation on lookup_fast function *) [ED] Add SMEP/WP bit verification (and re-enforcement) in more places *) [ED] Refactor some of the logic to be compatible with x86 lacking SMEP *) [ED] Add new sysctl lkrg.smep_panic (only on x86, enabled by default) *) [ED] Add new sysctl lkrg.umh_lock (disabled by default) *) Update INSTALL to document the new sysctl's and the previously undocumented lkrg.hide sysctl *) Minor change of initialization logic *) Add potential debug compilation option to Makefile *) Mute the most noisy STRONG_DEBUG output by default *) Don't export global CFLAGS since it might be incompatible when LKRG is part of a bigger project's build *) Restore terminal colors when systemd service installation fails 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. Like the previous time, Ilya Matveychikov came up with LKRG 0.6 exploit detection bypasses shortly after we released that version - thanks! Ilya demonstrated those bypasses in the form of further changes to Andrey Konovalov's exploit for CVE-2017-1000112: https://www.openwall.com/lists/lkrg-users/2019/02/21/1 My response: https://www.openwall.com/lists/lkrg-users/2019/02/20/2 Adam's response: https://www.openwall.com/lists/lkrg-users/2019/02/21/2 The new bypasses rely on executing the exploit's custom code in kernel mode in order to either setup stack frames that satisfy LKRG's pCFI or disable kprobes. This relies on the system lacking SMEP (Supervisor Mode Execution Protection) or LKRG not enforcing SMEP to a sufficient extent. In response to these bypasses, shortly after the 0.6 release Adam introduced (and pushed to Bitbucket) extra SMEP enforcement (now included in the 0.7 release). LKRG will now panic the kernel (behavior that can be disabled with a sysctl) if SMEP was enabled but somehow got unexpectedly disabled (previously, LKRG would merely re-enable SMEP in that case). We'll see what's next (probably use of more ROP gadgets?) And yes, we accept that LKRG is easier to bypass on systems that lack SMEP support (older CPUs and/or kernels). 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.