|
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: [openwall-announce] 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.