[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200620224903.GD1431@pi3.com.pl>
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.
