[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ae1f2752-946b-55db-f834-1bb7753e0b8f@gmail.com>
Date: Sun, 14 Jun 2020 20:21:39 +0200
From: Mikhail Morfikov <mmorfikov@...il.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: rootkit detection
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.
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.
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. :)
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
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.
