Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Nov 2019 23:50:18 +0100
From: Adam Zabrocki <>
Subject: Re: LKRG Security Questions


> 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:

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:

> 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:

> 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 
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
> > 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
        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:

> 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 


> Kind regards,
> Patrick
> [1]
> > 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

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.