[<prev] [next>] [day] [month] [year] [list]
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: 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.
