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