[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20210412202241.GA6205@openwall.com>
Date: Mon, 12 Apr 2021 22:22:41 +0200
From: Solar Designer <solar@...nwall.com>
To: announce@...ts.openwall.com, lkrg-users@...ts.openwall.com
Subject: LKRG 0.9.0
Hi,
For those new to LKRG, it is a kernel module that performs runtime
integrity checking of the Linux kernel and detection of security
vulnerability exploits against the kernel.
We've just released LKRG 0.9.0, now available at the usual location:
https://www.openwall.com/lkrg/
The following major changes have been made between LKRG 0.8.1 and 0.9.0:
*) Support new mainline kernel versions 5.8 to 5.12 (inclusive) and new stable
kernels 5.4.87+ (which include some back-ports from 5.8+)
*) Support new RHEL kernels up to RHEL 8.4's (inclusive)
*) Support building LKRG in the kernel tree (not only as a standalone module),
as a module or linking into the kernel image (see scripts/copy-builtin.sh)
*) Support CONFIG_FUNCTION_TRACER with or without CONFIG_DYNAMIC_FTRACE
*) Support various CONFIG_OPTPROBES configurations
*) Support loading overlayfs[2] after LKRG (e.g., by Docker; previously, the
overlayfs[2] module had to be loaded before LKRG for Docker to work)
*) "Support" CONFIG_GCC_PLUGIN_RANDSTRUCT (don't monitor SELinux if enabled)
*) Explicitly do not support RT kernels
*) Fix support for 32-bit x86 (was unintentionally broken in LKRG for ages,
but could mostly work on many pre-5.7 kernel and LKRG builds by "luck")
*) Fix detection of process user/group ID corruption to cover any unexpected
changes (previously, only numerically lower new IDs, as exploits normally
use, would be detected - a limitation left over from early LKRG testing)
*) Fix logging of WP/SMEP/SMAP violations on systems with SMAP in the "log and
accept" mode (previously, one such violation could mute logging of others)
*) Add detection of ADDR_LIMIT corruption attacks
*) Remove validation of waking-up tasks (drop pint_validate=2)
*) Replace execve(2) hooks (instead hook security_bprm_committing_creds and
security_bprm_committed_creds, which shortens the race window for exploits)
*) Replace ptrace(2) hooks (instead hook security_ptrace_access)
*) Simplify UMH blocking and make it compatible with CPA-protected pages
*) Simplify and speed up do_exit hook (no need to validate a dying process)
*) Many other changes under the hood to make LKRG easier to maintain and debug
*) Integrate LKRG with out-of-tree (a tool to assist kernel module testing)
*) Integrate LKRG with mkosi (systemd's tool for generating a test boot image)
*) Continuous Integration setup: boot tests on GitHub Actions using mkosi
(with Ubuntu's release kernels and their daily builds of mainline kernels)
As you can see, we had to make changes to support Linux kernels newer
than those available at the time of previous release. Almost every
major kernel release, and some back-ports too, broke compatibility with
LKRG. Since we did not make new LKRG releases, people with those newer
kernels were advised (on the LKRG homepage and otherwise) to use our
latest code off GitHub, which we tried to keep in a stable state (lately
in part through use of Continuous Integration). We also preserved
support for all of the old kernels we supported previously (RHEL7, etc.)
LKRG 0.8.1 was already smaller than 0.8, and with 0.9 the LKRG source
code became a bit smaller again (at least in terms of line count) due to
the simplifications we made, despite of significant additions:
$ git diff --shortstat v0.8.1..v0.9.0
126 files changed, 3919 insertions(+), 4375 deletions(-)
Also, perhaps in part due to our move to GitHub, we started to receive
more direct contributions to LKRG development (GitHub pull requests).
The full list of direct contributors to this release is:
$ git shortlog -sn v0.8.1..v0.9.0
67 Adam 'pi3' Zabrocki
15 Solar Designer
12 Mariusz Zaborski
7 Vladimir D. Seleznev
5 0xC0ncord
5 RageLtMan
5 Vitaly Chikunov
2 F0x1fy
1 William
1 disrupttheflow
I'd like to specifically highlight the contribution of support for
building LKRG in-tree (scripts/copy-builtin.sh and related testing) by
RageLtMan and the contribution of mkosi integration and Continuous
Integration setup by Vitaly Chikunov. I'd also like to highlight
Mikhail Klementev's offer to use his out-of-tree framework, which Adam
eventually added the integration for.
Adam also contributed the following for inclusion in this announcement:
---
During LKRG development and testing I've found 7 Linux kernel bugs, 4 of them
have CVE numbers (however, 1 CVE number covers 2 bugs):
CVE-2021-3411 - Linux kernel: broken KRETPROBES and OPTIMIZER
CVE-2020-27825 - Linux kernel: Use-After-Free in the ftrace ring buffer
resizing logic due to a race condition
CVE-2020-25220 - Linux kernel Use-After-Free in backported patch for
CVE-2020-14356 (affected kernels: 4.9.x before 4.9.233,
4.14.x before 4.14.194, and 4.19.x before 4.19.140)
CVE-2020-14356 - Linux kernel Use-After-Free in cgroup BPF component (affected
kernels: since 4.5+ up to 5.7.10)
I've also found 2 other issues related to the ftrace UAF bug (CVE-2020-27825):
- Deadlock issue which was not really addressed and devs said they will take a
look and there is not much updates on that.
- Problem with the code related to hwlatd kernel thread - it is incorrectly
synchronizing with launcher / killer of it. You can have WARN in kernels all
the time.
CVE-2021-3411 refers to 2 different type of bugs:
- Broken KRETPROBE (recently reported)
- Incompatibility of KPROBE optimizer with the latest changes in the linker.
Additionally, I've also found a bug with the kernel signal handling in dying
process:
CVE-2020-12826 - Linux kernel prior to 5.6.5 does not sufficiently restrict
exit signals
However, I don't remember if I found it during my work related to LKRG so I'm
not counting it here (otherwise it would be total 8 bugs while 5 of them would
have CVE).
That's pretty bad stats... However, it might be an interesting story to say
during LKRG announcement of the new version. It could be also interesting talk
for conference.
---
The kretprobes and ftrace issues here are of questionable security
relevance (this functionality is not exposed for attack under most
reasonable threat models), but all of these are interesting bugs.
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.
