Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20220722191716.GA2269@openwall.com>
Date: Fri, 22 Jul 2022 21:17:16 +0200
From: Solar Designer <solar@...nwall.com>
To: announce@...ts.openwall.com, lkrg-users@...ts.openwall.com
Subject: [openwall-announce] LKRG 0.9.4

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.4, available on the LKRG project website:

https://lkrg.org

The following major changes have been made between LKRG 0.9.3 and 0.9.4:

 *) Support new longterm kernels 5.15.40+
 *) Support the OpenRC init system
 *) Make log messages more consistent and suitable for both automated analysis
    and human consumption, as well as easier to maintain
 *) Introduce LKRG's own message severities and categories, which are separate
    from (but mapped onto) the kernel's and are included in messages themselves
 *) Many minor bug fixes, issue workarounds, and significant code cleanups
 *) Rename the module from p_lkrg to lkrg
 *) Add instructions on installing using DKMS
 *) Continuous Integration updates

We are lucky that our previous release, LKRG 0.9.3, works as-is on newer
mainline kernels up to 5.19-rc* so far.  However, for compatibility with
longterm 5.15.40+ kernels, which made a certain backport from newer
mainline, we had to enable the corresponding support in LKRG as well -
in our git repository a month ago, and now also in our new release.

The log messages rework also involved compacting the source code, to
reduce duplication.  As a result, despite of some additions, the source
code is now significantly smaller:

$ git diff --shortstat v0.9.3..v0.9.4
 97 files changed, 1744 insertions(+), 3034 deletions(-)

The changes this time are by the following people:

$ git shortlog -sn v0.9.3..v0.9.4
    38  Solar Designer
     4  Vitaly Chikunov
     3  Adam 'pi3' Zabrocki
     1  Kenton Groombridge
     1  Krish-sysadmin
     1  RageLtMan
     1  lc85446
     1  mrl5
     1  yeggor

In related industry and community news, a loosely similar eBPF-based
project called Tetragon was announced:

https://isovalent.com/blog/post/2022-05-16-tetragon/
https://github.com/cilium/tetragon

As I recall, initially the blog post above included a demo of Tetragon
catching a certain exploit, but a security researcher promptly modified
the exploit to bypass Tetragon and this was then removed?  Those events
prompted renewed criticism of post-exploitation mitigations:

https://grsecurity.net/tetragone_a_lesson_in_security_fundamentals

It's on those news that a fork of LKRG called VED (Vault Exploit
Defense) was released publicly:

https://hardenedvault.net/blog/2022-06-16-ved-community-version/
https://github.com/hardenedvault/ved

(Unfortunately, without it being visibly a fork in GitHub terms.)

At this time, VED is basically LKRG from 1.5 months ago plus one commit
adding more integrity checks.  Some of those are VED's additional
self-defense catching the Tetragon bypass technique.

We're considering related (but likely different) changes for inclusion
in LKRG proper.  LKRG does include some self-defense already - for
example, its runtime configuration is on a memory page that's kept
read-only most of the time, and it does not blindly trust its own
per-task flags (requiring per-load-randomized magic values there) -
but there's much room for improvement.

Also relevant is VED's list of recent exploits that it catches.  We'd
expect LKRG to catch almost all of those as well, but we did not do our
own testing with most of them.  We did happen to test the CVE-2021-3490
exploit by Valentina Palmiotti (@chompie1337), which LKRG does catch:

https://www.graplsecurity.com/post/kernel-pwning-with-ebpf-a-love-story
https://github.com/chompie1337/Linux_LPE_eBPF_CVE-2021-3490/pull/1

As usual, we welcome any feedback on the lkrg-users mailing list.  The
mailing list became inactive lately, though, with people opening GitHub
issues instead (good for actual issues we need to track, not so good for
general questions and discussions).

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.