Openwall Project Kernel Module Release (Linux Kernel Runtime Guard), designed to detect and block attacks and integrity violations in kernel structures. For example, the module can protect against unauthorized modifications to the running kernel and attempts to change user process privileges (determining the application of exploits). The module is suitable for providing protection against known kernel exploits (e.g., in situations where updating the kernel is problematic) as well as counteracting exploits for currently unknown vulnerabilities. Project code is licensed under GPLv2.
Among the changes in the new version:
- The positioning of the LKRG project has been changed so that it is no longer divided into separate subsystems for integrity checking and exploit detection, but presented as a cohesive product for detecting attacks and various integrity violations;
- Compatibility has been ensured with Linux kernels from 5.3 to 5.7, as well as with kernels compiled with aggressive GCC optimizations, without CONFIG_USB and CONFIG_STACKTRACE options or with CONFIG_UNWINDER_ORC option, as well as with kernels that lack interceptable LKRG functions, provided they can be omitted;
- During compilation, verification of some mandatory kernel CONFIG_* settings is ensured to produce meaningful error messages instead of vague failures;
- Support for sleep (ACPI S3, suspend to RAM) and hibernate (S4, suspend to disk) modes has been added;
- Support for DKMS has been added to the Makefile;
- Experimental support for 32-bit ARM platforms has been implemented (tested on Raspberry Pi 3 Model B). Previously available support for AArch64 (ARM64) has been extended to ensure compatibility with the Raspberry Pi 4 board;
- New hooks have been added, including a capable() call handler for better exploit detection, manipulating '', rather than process IDs ();
- A new logic for detecting attempts to escape namespace constraints (e.g., from Docker containers) has been proposed;
- On x86-64 systems, verification and application of the SMAP bit (Supervisor Mode Access Prevention) has been ensured, which is designed to block access to user space data from privileged code running at kernel level. SMEP (Supervisor Mode Execution Prevention) was implemented earlier;
- During operation, LKRG settings are placed in memory pages that are usually read-only;
- Logging output of information that may be most useful for attacks (e.g., kernel address information) is limited to debug mode (log_level=4 and above), which is disabled by default.
- Increased scalability of the process tracking database — instead of one RB tree protected by a single spinlock, a hash table of 512 RB trees is employed, each protected by 512 read-write locks.
- A mode has been implemented and is enabled by default, in which the integrity check of process identifiers is often performed only for the current task, and optionally for activated (waking) tasks. For other tasks that are sleeping or operating without calls to the kernel's controlled LKRG API, the check is performed less frequently.
- New sysctl and module parameters for fine-tuning LKRG have been added, as well as two sysctl options for simpler configuration by selecting from prepared developer sets of tuning profiles.
- Default settings have been changed to achieve a more balanced trade-off between the speed of detecting violations and the efficiency of response on one hand, and the impact on performance and the risk of false positives on the other.
- The systemd unit file has been redesigned to load the LKRG module at an early stage of boot (the module can be disabled using a kernel command-line parameter).
With the optimizations suggested in the new release, the performance impact of using LKRG 0.8 is estimated at 2.5% in default mode ('heavy') and 2% in lightweight mode ('light').
In a recently conducted of the effectiveness of LKRG rootkit detection packages the best results, with no false positives, identified 8 out of 9 tested rootkits operating at the kernel level (rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit, and Sutekh were detected, while Keysniffer, which is a kernel module with a keylogger and not a rootkit in the strict sense, was missed). For comparison, the packages AIDE, OSSEC, and Rootkit Hunter detected 2 rootkits out of 9, while Chkrootkit detected none. At the same time, LKRG does not support detection of user-space rootkits, hence the highest effectiveness is achieved when using the combination of AIDE and LKRG, allowing for the detection of 14 out of 15 rootkits of all types.
Additionally, it is worth noting that the developer of the distribution started of ready-made packages with DKMS for Debian, Whonix, Qubes, and Kicksecure, while the package for has already been updated to version 0.8. Packages with LKRG are also available in Russian and .
Integrity checks in LKRG are performed based on the comparison of the actual code and data of the kernel and modules, some important data structures and CPU settings with saved hashes or copies of the corresponding memory areas, data structures, or registers. Checks are activated both periodically by a timer and upon the occurrence of various events.
Determining potential exploit applications and blocking attacks takes place at the stage before the kernel grants access to resources (for example, before opening a file), but after the process gains unauthorized privileges (for instance, changing UID). Upon detecting unauthorized process behavior, termination is performed by default, which is sufficient to block many exploits.
Source: opennet.ru
