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