[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Nov 2019 23:50:18 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: LKRG Security Questions
Hi,
> This may be a speculative question, but how likely is it that malware
> would specifically target LKRG in order to exploit or escalate
> privileges? Did this happen in-the-wild with off-the-shelf malware [1] yet?
>
I believe it depends on LKRG's popularity. If LKRG becomes widely adopted,
malware in the kernel will be somehow 'forced' to deal with it and find a way
to do what they want. Nevertheless, in such scenario LKRG ends-up being in the
same shoes as Windows' PatchGuard is:
https://en.wikipedia.org/wiki/Kernel_Patch_Protection
Or any other PatchProtection solution.
For now we have not seen that scenario happend in the wild (or we are not aware
about it).
> How big is the attack surface that LKRG adds vs the security advantages
> gained from LKRG?
>
It is difficult for me to have a 'clear answer'. LKRG is not relying on any
data coming from the user-mode (excluding sysctl interface). LKRG mostly
'snapshots' the values ââ/ state from the other subsystems in the
kernel and syncs it during maintenance. Attacking vector for LKRG requires
changing the data which LKRG is based on (so kernel memory). Because of that *
I believe * the potential problems with LKRG are limited. Of course there are
some caveats like, if you do fork() - like bomb, LKRG is snapshoting metadata
for each newly created process / thread which means memory footprint etc. Maybe
there is a way to do smth more comparing to what I'm aware of.
> Have there been any reports or first hand experiences with
> (off-the-shelf) malware vs LKRG yet?
>
You might be interested in this thread:
https://twitter.com/cr0nym/status/1063368081530077184
https://www.defensive-security.com/blog/playing-with-linux-kernel-runtime-guard-lkrg
> Are there any trial exploits and/or instruction to verify LKRG is load
> and effective? Maybe an automated test suite / unit testing that could
> be run by developers and/or users?
I have private project for that. I have vulnerable driver with various
primitives and a few different exploits trying to leverage them in various
ways. That's how I test it.
Nevertheless, I still have a few gaps (mostly multi-arch issue) there which I
cover manually.
>
> LKRG wouldn't stop "simple" trojan horses? By that, I mean a trojan
> horse comparable with a "remote SSH shell" or "remote VNC session" which
> the user is unaware off? I.e. a simple process not trying to gain kernel
> access. Imagine a user who executes "cute cat" binary, resulting in a
> forking "remote SSH shell"? Or a browser exploit that starts a "remote
> SSH shell"?
It wouldn't. Unless it is spawned by the kernel malware or do something similar
what Leszek descibed:
https://twitter.com/solardiz/status/1063510967588392961
> LKRG seems more useful to prevent kernel compromise with the
> goal to prevent a rootkit and/or with the goal to prevent outbreak from
> a virtual machine (which may require a chain of exploits such as browser
> exploit -> kernel exploit -> VM breakout)?
>
Correct. It was designed to protect kernel.
> Which types of security vulnerabilities (SWAPGS? ...) are (probably)
> insufficient to bypass LKRG?
>
If you don't have full R/W it will be difficult to bypass LKRG. Some types of
vulnerabilities (as you mentioned SWAPGS-like) can never be converted to full
R/W.
Partial R/W might be insufficient as well but it depends on what attacker can
do with it (and what is "visible" to the attacker).
Additionally, attacking LKRG is type of race-condition. Even if you can bypass
LKRG (sufficient primitives), there is a chance that you won't be fast enough
to stay invisible. Depending on the type of primitive this race might be
trivial or non-trivial. However, there is still a chance that reliability of
the exploitation might be dropped and LKRG might have a chance (even small) to
catch you.
> Quote https://www.openwall.com/lkrg/
>
> > 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)
>
>
> Would it be possible / sane to kernel panic in such cases? Perhaps with
> a clearly written message on the user's screen for informational
> purposes? Or dispatch a configurable hook script that could specify the
> response?
>
That's because we didn't update the documentation. We have an optional feature
to panic() the system in case of CI integrity violation:
"-> Kernel panic on CI failure (lkrg.ci_panic) - only two options are
available:
0 - do NOT crash the kernel on CI failure (default)
1 - crash the kernel (call panic()) on CI failure"
All configurable options (updated doc) can be found in INSTALL file:
https://bitbucket.org/Adam_pi3/lkrg-main/raw/17ae51c73bba84dc697fd13be5941d4709a87a08/INSTALL
> Also if/when time allows, could you please consider submitting the LKRG
> module to the mainline linux kernel? If that makes sense? Even if
> (likely?) rejected, it might help with popularity, source code review?
>
I believe to be able to do that we would need to rewrite coding style to match
Linux kernel's one. We had a discussion with Alexander Gusev from Astra Linux
about that. Because of my fault (busy schedule) I didn't have time to move that
forward:
https://www.openwall.com/lists/lkrg-users/2019/09/25/1
Thanks,
Adam
> Kind regards,
> Patrick
>
> [1]
> https://www.whonix.org/wiki/Malware#Targeted_Malware_vs_Off-The-Shelf_Malware
>
> > Targeted Malware vs Off-The-Shelf Malware
> >
> > Targeted malware is the opposite of off-the-shelf malware.
> >
> > Targeted malware is specifically crafted against a known target to attack a
specific system or limited amount of systems only with the goal to avoid
detection by avoiding getting
> +installed on too many where qualified people might detect the malware and
publish about it.
> >
> > On other other hand, off-the-shelf malware attempts to spread in bulk
against bigger groups or the general public with the goal of taking over as
many systems as possible.
>
>
> (Defining these terms since often people wonder what I mean by that.
> Talking to general public, not only to specific people who probably know
> this already.)
>
--
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.
