Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 21 Jun 2020 00:49:03 +0200
From: Adam Zabrocki <>
Subject: Re: rootkit detection


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

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.