OpenWall unveils kernel protection project

Guarding the kernel against unauthorised changes

The folk at OpenWall have called for assistance to create a security module to watch Linux kernels for suspicious activity.

In the company's explanation, the Linux Kernel Runtime Guard (LKRG) is described as a module that “attempts to post-detect and hopefully promptly respond to unauthorised modifications to the running Linux kernel (integrity checking) or to credentials (such as user IDs) of the running processes (exploit detection).”

Developed by Adam Zabrocki (@adam_pi3) and now championed by OpenWall, the first cut of the code landed last week.

It's imperfect for now and OpenWall admits it: “While LKRG defeats many pre-existing exploits of Linux kernel vulnerabilities, and will likely defeat many future exploits (including of yet unknown vulnerabilities) that do not specifically attempt to bypass LKRG, it is bypassable by design (albeit sometimes at the expense of more complicated and/or less reliable exploits).”

The LKRG wiki explains that it works by calculating hashes of important kernel regions, sections, and structures against the “internal database hashes”.

Ideally, LKRG should be run on a known-clean system (that is, after a brand-new install has been booted); it creates its trusted database of hashes against that environment, and uses those hashes to watch for changes.

As this is a first cut of the LKRG (as in, it's version 0.0), there's a substantial to-do list. Currently, it covers critical CPU/core data for x86 and amd64 architectures; the Linux Kernel .text section (the notes say “This covers almost [the] entire Linux kernel itself, like syscall tables, all procedures, all function, all IRQ handlers, etc”), the Linux kernel exception table, the read-only .rodata section, the IOMMU I/O mappings, and loaded modules.

OpenWall said LKRG has been tested in various scenarios, and at the same time, notes the kinds of limitations that apply:

“In our testing on vulnerable distro kernels LKRG successfully detected certain pre-existing exploits of CVE-2014-9322 (BadIRET), CVE-2017-5123 (waitid(2) missing access_ok), CVE-2017-6074 (use-after-free in DCCP protocol). However, it wouldn't be expected to detect exploits of CVE-2016-5195 (Dirty COW) since those directly target the userspace even if via the kernel”

Zabrocki also has a Patreon for the project. ®

Similar topics

Other stories you might like

Biting the hand that feeds IT © 1998–2021