Openwall project kernel module release (Linux Kernel Runtime Guard), designed to detect and block attacks and violations of the integrity of kernel structures. For example, the module can protect against unauthorized changes to the running kernel and attempts to change the permissions of user processes (exploit detection). The module is suitable both for organizing protection against already known exploits for the Linux kernel (for example, in situations when it is problematic to update the kernel in the system), and for countering exploits for yet unknown vulnerabilities. Project code licensed under GPLv2.
Among the changes in the new version:
- The positioning of the LKRG project has been changed, which is no longer divided into separate subsystems for checking the integrity and determining the use of exploits, but is presented as an integral product for detecting attacks and various integrity violations;
- Ensured compatibility with Linux kernels from 5.3 to 5.7, as well as kernels built with aggressive GCC optimizations, without the CONFIG_USB and CONFIG_STACKTRACE options or with the CONFIG_UNWINDER_ORC option, as well as with kernels that lack LKRG-hooked functions, if they can be dispensed with;
- When building, some mandatory CONFIG_* kernel settings are checked to generate meaningful error messages instead of obscure crashes;
- Added support for standby (ACPI S3, suspend to RAM) and sleep (S4, suspend to disk) modes;
- DKMS support added to Makefile;
- Implemented experimental support for 32-bit ARM platforms (tested on Raspberry Pi 3 Model B). Previously available support for AArch64 (ARM64) has been updated to ensure compatibility with the Raspberry Pi 4 board;
- New hooks have been added, including a capable() call handler to better detect exploits that manipulate "", not process IDs ();
- A new logic has been proposed for detecting attempts to exit namespace restrictions (for example, from Docker containers);
- On x86-64 systems, the SMAP (Supervisor Mode Access Prevention) bit is checked and enforced to block access to user-space data from privileged code running at the kernel level. SMEP (Supervisor Mode Execution Prevention) protection was implemented earlier;
- During operation, LKRG settings are placed in a memory page, usually read-only;
- The output to the logs of information that can be most useful for attacks (for example, information about addresses in the kernel) is limited to debugging mode (log_level=4 and higher), disabled by default.
- Increased scalability of the process tracking database - instead of one RB tree protected by one spinlock, a hash table of 512 RB trees is used, respectively protected by 512 read-write locks;
- A mode has been implemented and enabled by default, in which the integrity check of process identifiers is often performed only for the current task, and also optionally for activated (waking up) tasks. For other tasks that are in the sleep state or work without a call to the kernel API controlled in the LKRG, the check is performed less often.
- Added new sysctl and module parameters for fine-tuning LKRG, as well as two sysctl for simplified configuration by choosing from fine-tuning sets (profiles) prepared by developers;
- The default settings have been changed to achieve a more balanced balance between the speed of detection of violations and the effectiveness of the reaction on the 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 (a kernel command line option can be used to disable the module);
Taking into account the optimizations proposed in the new release, the performance degradation when using LKRG 0.8 is estimated at 2.5% in the default mode (βheavyβ) and 2% in the βlightβ mode (βlightβ).
In a recent effectiveness of packages for detecting rootkits LKRG best results, without false positives, identifying 8 out of 9 rootkits tested that work at the kernel level (Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit and Sutekh rootkits were detected, but Keysniffer, which is a kernel module, was omitted with a keylogger, not a rootkit in the literal sense). In comparison, AIDE, OSSEC and Rootkit Hunter detected 2 rootkits out of 9, while Chkrootkit did not detect any. At the same time, LKRG does not support the detection of user-space rootkits, so the greatest efficiency is achieved when using the AIDE and LKRG bundle, which made it possible to detect 14 out of 15 rootkits of all types.
Additionally, it can be noted that the developer of the distribution kit started ready-made packages with DKMS for Debian, Whonix, Qubes and Kicksecure, and a package for already updated to version 0.8. Packages with LKRG are also present in Russian ΠΈ .
Integrity checking in LKRG is performed by comparing 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 when various events occur.
The detection of the possible use of exploits and the blocking of attacks are performed at the stage before the kernel provides access to resources (for example, before opening a file), but after the process has received unauthorized permissions (for example, changing the UID). By default, if processes are found to behave inappropriately, they are forcefully terminated, which is sufficient to block many exploits.
Source: opennet.ru