Date: Sun, 21 Jun 2020 00:49:03 +0200 From: Adam Zabrocki <pi3@....com.pl> To: lkrg-users@...ts.openwall.com Subject: Re: rootkit detection Hi, On Sun, Jun 21, 2020 at 12:23:14AM +0200, Solar Designer wrote: > On Sun, Jun 14, 2020 at 08:21:39PM +0200, Mikhail Morfikov wrote: > > On 14/06/2020 17:37, Solar Designer wrote: > > > Of course, none of these rootkits tried to bypass LKRG. If they wanted > > > to, they could e.g. simply "rmmod p_lkrg" before loading themselves into > > > the kernel. (Or the attacker could do that manually.) In LKRG > > > development, we're currently more focused on exploits run before the > > > attacker got legitimate-looking privileged access to the system. We're > > > not as focused on rootkits, which are loaded with legitimate-looking > > > privileged access. > > > > Removing the LKRG module via "rmmod p_lkrg" sometimes may not be so easy. In the > > case of my Debian system, I have the Secure Boot mode enabled. Also since kernel > > 5.4 there's the kernel lockdown mechanism, and in Debian it also was extended by > > the CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT option, which automatically sets the > > kernel lockdown mode when the system is booted with Secure Boot enabled. So with > > the kernel lockdown, you can't load modules that weren't signed by some verified > > keys, and loading modules like the Keysniffer would simply fail in such systems. > > I also removed the default EFI certs and added my own certs to the firmware in > > the place of the older ones to make sure that the kernel/bootloader (and > > anything else) can be loaded only when it was signed by me, and only me. > > > > Also even if someone doesn't use the Secure Boot/Kernel lockdown mode, there's > > CONFIG_MODULE_SIG_FORCE, which can prevent loading unsigned modules and stop > > them from doing some harm in the system, though it's not default in the distro > > kernels. But having either one setup would make extremely hard or impossible to > > load any additional unsigned modules in a working system. > > Sure there are ways to harden the system like that. However, as long as > those protections work, LKRG's LKM rootkit detection is irrelevant. And > when they fail, the LKRG unload attack (or its variation) would work. > > Besides, someone with legitimate-looking root access can also disable > LKRG via sysctl's. So hardening LKRG against rmmod only makes sense > along with hardening against sysctl. Like I wrote, in a future version > both interfaces might be optionally password-protected (or disabled). > Right. It is worth to mention that if you are an attacker, and archieve R/W primitive in the kernel, you can load your rootkit into the kernel memory without using any modules. In such case, LKRG might still catch rootkit activities even attacker bypassed CONFIG_MODULE_SIG_FORCE. > > Even if none of the above solutions would be used, there's still the > > CONFIG_MODULE_UNLOAD option that can prevent the LKRG module from being > > unloaded, but since LKRG depends on this option (it has to be set to "yes"), it > > asks itself for troubles, especially on the systems where Secure Boot/Kernel > > lockdown isn't an option. So not forcing people to have CONFIG_MODULE_UNLOAD > > enabled would simply help the LKRG module (and other security modules) from > > being unloaded in such cheap way. > > Yes, we should probably enhance LKRG to support builds without > CONFIG_MODULE_UNLOAD. However, that wouldn't currently matter for > security because of the sysctl's. > > > Also there's, a kernel sysctl option provided by LKRG, which is > > lkrg.block_modules, but this is rather weak now, since it simply block loading > > of modules when it's set. It actually doesn't prevent the LKRG module from being > > unloaded. But there's also the sysctl option kernel.modules_disabled, and this > > one (when set) blocks loading/unloading of modules, and reboot is required to > > change the value of this parameter. So to prevent LKRG from being unloaded, a > > user can set that last option to "1", but it always has to be done in working > > system when it boots, so it's not as strong as CONFIG_MODULE_UNLOAD, but it's > > better than nothing. :) > > FWIW, here's my tentative proposal from a few months ago for replacing > lkrg.block_modules, which we ended up not doing yet: > > --- > modules_enforce 0 no enforcement, 1 log only, 2 block loading, 3 block loading and unloading, 4 also lock this setting itself > (lkrg.modules_enforce=4 will be same as kernel.modules_disabled=1, except it'd also have LKRG's logging) > --- > > Do you like this? We might revisit it later. One reason why we didn't > go for it yet is that it'd be a tiny subset of the functionality to be > expected from a securelevel-alike feature. Adam actually had more of > the securelevel-alike functionality in LKRG experimental branch, which I > didn't like because I'd expect very few LKRG users to manage such > systems right (it's tricky, inconvenient, and time-consuming). That > branch is now abandoned and we don't intend to revitalize it. Besides, > upstream Linux got this lockdown thing instead of securelevel anyway. > > This proposal also didn't fit in well with our other *_enforce controls, > where there's no "no enforcement" option (and the value 0 means logging) > because there's a *_validate control where we have "disabled" as an > option. This would be the only *_enforce without a *_validate, > resulting in this inconsistency. Maybe using -1 for "no enforcement" > would be cleaner, so that the rest isn't shifted vs. other *_enforce? > > For now, we're going to document lkrg.block_modules as follows: > > --- > - lkrg.block_modules (0) > Whether or not to block further loading of kernel modules. Allowed values > are 0 (no) and 1 (yes). > > This feature is meant primarily to prevent unintended user-triggered (or > attacker-triggered) auto-loading of maybe-vulnerable modules provided in a > distribution after all intended modules have already been loaded. This > feature is not effective (nor is meant to be) against attackers who already > have root privileges and try to load a module explicitly (they could simply > flip this setting or even unload LKRG first). > --- > > Alexander -- pi3 (pi3ki31ny) - pi3 (at) itsec pl http://pi3.com.pl
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.