[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181112181421.GB27330@pi3.com.pl>
Date: Mon, 12 Nov 2018 19:14:21 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: LKRG 0.5
Hi,
On Mon, Nov 12, 2018 at 08:40:10PM +0400, Ilya Matveychikov wrote:
>
>
> > On Nov 12, 2018, at 8:21 PM, Solar Designer <solar@...nwall.com> wrote:
> >
> > On Mon, Nov 12, 2018 at 08:03:31PM +0400, Ilya Matveychikov wrote:
> >> On Nov 12, 2018, at 7:51 PM, Solar Designer <solar@...nwall.com> wrote:
> >>> Is the khook_demo module you have loaded part of what you call a LKRG
> >>> bypass, or is it some unrelated demo/test you ran? Is it part of what
> >>> caused the crash?
> >>
> >> Quick answer about KHOOK. You can find it at github:
> >> https://github.com/milabs/khook
> >
> > Thanks!
> >
> >>> If it's part of the bypass, then that wouldn't count per our threat
> >>> model unless you loaded the module while under illegitimate root access
> >>> obtained via a kernel vulnerability exploit (in which case "ED" is meant
> >>> to trigger on module loading attempt). Simple loading of kernel modules
> >>> (including custom ones) as legitimate root is allowed under LKRG -
> >>> including modules that would substantially modify system behavior (e.g.,
> >>> hook functions).
> >>
> >> And yes, it's a part of bypass where the point is that having protection
> >> system (LKRG) and "malicious" module at the same level of abstraction worth
> >> nothing to do with the security.
> >
> > You don't need a video to prove that indeed one can sort of "bypass"
> > LKRG by loading a kernel module. This is a case of "works as intended".
> > Maybe such video can be useful as illustration to LKRG users on what
> > kind of protection not to expect from LKRG. Maybe we also need to
> > improve our documentation in that respect - suggestions are welcome - if
> > some users would reasonably have different expectations from the way
> > LKRG is documented now.
>
>
> Well, I had no idea about what was the threat model. And you’re right,
> bypassing it from the kernel is quite trivial. Now I can understand LKRG
> concept better thanks to you.
>
Slightly more information about the Aim of the project can be found here:
https://openwall.info/wiki/p_lkrg/Main
Thread model is being discussed here:
https://openwall.info/wiki/p_lkrg/Threat_model
or you can try to see / watch my presentation about LKRG where I've tried to
explain what is the goal of LKRG. Additionally, we're always being opened about
limitation of this solution and in this presentation you can find documented
way of potential bypasses which we are aware of:
https://www.youtube.com/watch?v=tOiPM692DOM
> About the bypass “technique” which I wanted to show I could say that
> it can be used from the user-mode too. Just consider that the only way
> of LKRG to report something is to write to kernel’s log. So, simple
> filtering of entries by “[LKRG]” is enough to completely remove all the
> noise produced by LKRG. Valid for both kernel and user modes.
>
It depends. Exploit Detection feature kills tampered process (illegally
elevated) and write information to the kernel's log. Runtime CI failure on a
new version of LKRG (0.5) introduces new configuration option (via sysctl
interface) where in case of CI failure, LKRG will panic() the kernel (disabled
by default):
"*) [CI] Add new sysctl interface - optional panic() on CI verification
failure"
[root@...alhost ~]# sysctl -a |grep lkrg
lkrg.block_modules = 0
lkrg.ci_panic = 0
^^^^^^^^^^^^^^^^^
lkrg.clean_message = 1
lkrg.force_run = 0
lkrg.hide = 0
lkrg.log_level = 0
lkrg.random_events = 1
lkrg.timestamp = 15
If lkrg.ci_panic=1 LKRG will write CI assertion failure to the kernel's log and
then panic()
> >
> > LKRG "main" (unlike "experimental") doesn't include protection against
> > root in its threat model, except when said root access was just obtained
> > via a kernel vulnerability exploit. I see nothing inconsistent in that.
> > Do you? If so, what inconsistency do you see?
>
> Well, it’s a good question. Is it OK for the OS kernel to be exploited
> by exploits by itself and this is the case to have things like LKRG or
> should the kernel be designed in the way that having a BUG doesn’t give
> attacker a way to exploit it?
>
This is a very binary approach to the complicated problem. In reality there
might be a various different reasons why immediate kernel update is not an
option:
- machine has custom solution, where kernel update might break it
- machine might have modified kernel, where update is not straightforward
- machine might run kernel code incompatible with the new update
- machine might be in the critical infrastructure, where immediate delay is
not an option
- machine might host a service which requires time to set-up environment which
allows update
- much more which can be listed here
Without LKRG, these environment are strongly open and vulnerable even to script
kiddies which don't understad what they try to run, automatic epxloit kids,
malware, etc. LKRG will block that kind of not-targeted attacks and brings a
value (and "buy" some time to update).
Additionally, LKRG might stop 0days which are not designed to deal with LKRG,
so even fully-update machine might benefits from it.
LKRG is not designed to replace secure kernels, neither to stop updates, but it
brings extra layer of security where sometimes it might be valuable. Going more
into this fields, if specific vulnerability do not gives an attacker full R/W
primitives (like BadIret, Sysret, PopSS vulns), LKRG will be very difficult to
bypass (if at all). If vulnerability is powerfull and gives Full R/W in the
kernel, if code do not target LKRG, it will be stopped. It is common that
people which write the exploit are not the one who run them, so if they don't
have code targetting LKRG - they will be blocked. Additionally, If someone
targetting LKRG is not careful, it reduces relability of exploitation - it
brings extra security value, etc.
Moreover, I believe LKRG is no different than any other security-like
solutions, e.g.:
- firewalls are trivial to bypass, but you won'd disable them because of that
- IDS are trivial to bypass - but people still see value of using it
- Some mititgation are trivial do bypass, but you still want them to be
enabled:
*) ASLR by itself is weak and trivial to bypass
*) DEP by itself is weak and trivial to bypass
*) Same with SMEP
*) more
But each of the solution "slightly rises the bar". LKRG is no different here.
Thanks,
Adam
> That’s the only inconsistency I can see.
>
> In other words, probably it’s better to concentrate on fixing OS kernel
> security rather than developing of runtime guards :)
>
> >
> > To me, that's a reasonable and consistent threat model, even if limited.
> >
> > 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.
