[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20180129210522.GA25089@openwall.com>
Date: Mon, 29 Jan 2018 22:05:22 +0100
From: Solar Designer <solar@...nwall.com>
To: announce@...ts.openwall.com, lkrg-users@...ts.openwall.com
Subject: [openwall-announce] Linux Kernel Runtime Guard
Hi,
This is to announce our most controversial project ever.
Linux Kernel Runtime Guard (LKRG) is a loadable kernel module that
performs runtime integrity checking of the Linux kernel and detection of
security vulnerability exploits against the kernel. As controversial as
this concept is, LKRG attempts to post-detect and hopefully promptly
respond to unauthorized modifications to the running Linux kernel
(integrity checking) or to credentials (such as user IDs) of the running
processes (exploit detection). For process credentials, LKRG attempts
to detect the exploit and take action before the kernel would grant the
process access (such as open a file) based on the unauthorized
credentials. You can download the current experimental version of LKRG
at its brand new homepage:
http://www.openwall.com/lkrg/
LKRG is mostly due to work by Adam 'pi3' Zabrocki, has been in
(re-)development for a couple of years, and builds upon Adam's prior
experience with a related project in 2011. I contributed some ideas to
the project starting last year, significantly changing the focus of this
initial public release. I did not contribute any code yet, though.
We would also like to acknowledge related ideas by Kirill Korotaev from
CloudLinux / Virtuozzo, who communicated them to me privately a few
years ago. And we'd like to mention, as independent related work, the
Additional Kernel Observer (AKO) project by Yuichi Nakamura from Hitachi
and Toshihiro Yamauchi from Okayama University as announced at Linux
Security Summit 2017 and discussed/criticized in:
http://www.openwall.com/lists/kernel-hardening/2017/09/22/3
LKRG differs from AKO in a number of ways, including LKRG being an LKM
rather than a patch, LKRG performing occasional integrity checking of
most of the rest of the kernel and not only of process credentials, and
LKRG being less immature.
While LKRG defeats many pre-existing exploits of Linux kernel
vulnerabilities, and will likely defeat many future exploits (including
of yet unknown vulnerabilities) that do not specifically attempt to
bypass LKRG, it is bypassable by design (albeit sometimes at the expense
of more complicated and/or less reliable exploits). Thus, it can be
said that LKRG provides security through diversity, much like running an
uncommon OS kernel would, yet without the usability drawbacks of
actually running an uncommon OS.
As free LKRG becomes somewhat popular and maybe a target of some
exploits, we might introduce paid LKRG Pro as a means to fund the
project and provide further diversity (with Pro's smaller userbase being
beneficial), extra and specialized functionality (e.g., detection of
container escapes), and maybe distro-specific binary builds.
Like any software, LKRG may contain bugs and some of those might even be
new security vulnerabilities. You need to weigh the benefits vs. risks
of using LKRG. Our assessment is that the benefit vs. risk ratio for
LKRG when used on typical Linux systems isn't nearly as bad as it is for
typical Windows anti-virus and end-point security products (which we
also find controversial for similar reasons). LKRG's code size and
attack surface are much smaller than those products'. If you would use
those then you'd probably be OK using LKRG as well. If you wouldn't, or
if your Linux systems are otherwise hardened and/or always promptly
updated, then you could want to think twice about using LKRG as well.
LKRG is most useful for systems that realistically, despite of this
being a best practice for security, won't be promptly rebooted into new
kernels (nor live-patched) whenever a new kernel vulnerability is
discovered.
Being a kernel module (not a kernel patch), LKRG can be built for and
loaded on top of a wide range of mainline and distros' kernels, without
needing to patch those. We currently support kernel versions ranging
from RHEL7 (and some of its clones/revisions, including even the heavily
modified OpenVZ 7 / Virtuozzo 7, albeit not trying to detect container
escapes yet) and Ubuntu 16.04 to latest mainline.
LKRG is currently in an early experimental stage. We expect occasional
false positives (integrity violations and/or exploits detected when
there aren't ones). LKRG's current response to kernel integrity
violations is merely reporting those in kernel messages (which obviously
doesn't mitigate attacks when those are for real) and its current
response to unauthorized process credentials is killing the process
(which does defeat many exploits, but is a rather mild response
nevertheless). This will likely change as LKRG becomes more mature.
To illustrate LKRG's exploit detection capabilities, in our testing on
vulnerable distro kernels LKRG successfully detected certain
pre-existing exploits of CVE-2014-9322 (BadIRET), CVE-2017-5123
(waitid(2) missing access_ok), CVE-2017-6074 (use-after-free in DCCP
protocol). However, it wouldn't be expected to detect exploits of
CVE-2016-5195 (Dirty COW) since those directly target the userspace even
if via the kernel. While in case of Dirty COW the LKRG "bypass"
happened due to the nature of the bug and this being the way to exploit
it, it's also a way for future exploits to bypass LKRG by similarly
directly targeting userspace. It remains to be seen whether such
exploits become common (unlikely unless LKRG or similar become popular?)
and what (negative?) effect on their reliability this will have (for
kernel vulnerabilities where directly targeting the userspace isn't
essential and possibly not straightforward).
We did not focus on performance optimizations nor ran many benchmarks
yet, but to give a rough idea the performance impact of LKRG 0.0 on
building John the Ripper 1.8.0 with "make -j8" on an Atom C2750 machine
(8 Silvermont cores in 20W TDP) running VzLinux (Virtuozzo 7) appears to
be around 6.5%. We find this performance impact significant (especially
for a security measure bypassable by design), and are likely to make
adjustments to reduce it.
More information on LKRG is available on our wiki, you're welcome to
support the project on Patreon, and we've also setup a mailing list for
discussions around LKRG - lkrg-users. The corresponding links are
available on the LKRG homepage referenced above. Please direct any
questions or comments on LKRG to the lkrg-users mailing list.
Thanks for scrolling down this far.
Alexander
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.
