[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 20 Nov 2018 11:45:22 +0100
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: LKRG Exploit Detection bypass (LOL again)
On Tue, Nov 20, 2018 at 02:18:23AM +0400, Ilya Matveychikov wrote:
> On Nov 18, 2018, at 5:29 PM, Solar Designer <solar@...nwall.com> wrote:
> > There are many other convenient bypass possibilities as well. Adam's
> > thinking is we could detect many (ab)uses of kernel APIs from unexpected
> > places by analyzing call chains (through stack frames). My thinking is
> > we didn't intend to become a control flow integrity enforcement project,
> > and doing so from an LKM would be at best difficult.
>
> Control flow integrity must be a part of Linux kernel. That's the only
> way to do it properly.
Sure. Not arguing in favor of CFI enforcement in LKRG, but referring to
your word "properly", my opinion is that:
LKRG is not about doing things properly in the long run - it is about
providing temporary stop-gaps considering attacks currently common on
systems currently in use, especially poorly maintained systems. To be
useful for poorly maintained systems (where LKRG itself might not be
updated), the "temporary" and "currently" should span a few months to a
few years.
That said, there's an opinion, shared by Adam, that detecting/preventing
unsupported (not via proper APIs) modifications to the kernel is a
proper thing to have long-term, referring to other vendors' alternatives
that are meant to be long-term, such as Microsoft's PatchGuard and
Samsung's KNOX. Here's a Microsofter's perspective on PatchGuard in an
8-tweet thread:
https://twitter.com/depletionmode/status/958609786450464768
> > Then, if we're to provide "security through diversity" only, then even
> > having non-optional code integrity checking is excessive - exploits
> > typically don't patch kernel code, but only modify process credentials.
> > LKRG's code integrity checking does happen to detect some pre-existing
> > rootkits, though:
> >
> > https://www.defensive-security.com/blog/playing-with-linux-kernel-runtime-guard-lkrg
>
> Well, indeed kernel code patching is an attribute of almost all known
> kernel rootkits. And for sure CI makes it possible to detect this kind of
> software. But still I'm not sure about the value of LKRG in this case as
> in my opinion installing of kernel-based (or any other) rootkit is not
> the first step of compromising the system.
>
> I mean that the system is **already compromised** with escalated privileges
> which in fact means that the game is over.
Game over for one system isn't the same as game over for the
organization where that system is used. Earlier detection of the system
compromise and/or taking it offline (e.g., LKRG-induced kernel panic)
can be helpful.
> Except you want to keep LKRG
> working well for synthetic tests like "loading a well-known bad written
> publicly available github hosted r00tk1t".
Any test we can deliberately run ourselves (without a real-world attack
occurring on its own) is synthetic. However, those publicly available
rootkits are known to be actually used in some system compromises, e.g.
of kernel.org:
https://www.theregister.co.uk/2011/08/31/linux_kernel_security_breach/
"Kernel.org Linux repository rooted in hack attack
Rootkit not detected for 17 days"
"two security researchers who were briefed on the breach said the
infected systems were hit by a self-injecting rootkit known as Phalanx"
(This is confirmed in later news stories on the incident.)
Would LKRG have helped? We don't know. I guess this depends on whether
the attacker would have checked for it first, and on its configuration
(panic or not, log file monitoring or not, remote logging or not, etc.)
> > So rather than try to address these bypasses via ROP chains, maybe we
> > should take a step back and make CI optional, to be able to more
> > consistently target only typical exploits that don't try to bypass LKRG.
>
> Honestly this approach makes LKRG even more unusable :)
Thanks for your opinion.
Do I infer correctly that this implies you do see some value in LKRG,
after all? ;-)
> > On the offensive side, you could want to look into making exploits such
> > as Andrey's PoC you started with more portable across different kernel
> > builds. Instead of hard-coding many per-kernel offsets, can you
> > possibly find and program a weird machine that would pattern-search for
> > all other offsets it needs? Would this weird machine program require
> > fewer hard-coded addresses than it needs to find for the actual exploit?
> > If so, it'd be a net win. Pattern search is easier done when you're
> > running custom code (I had pattern search for WinExec in my Windows NT
> > shellcode in late 1996 for some portability across Windows builds while
> > not dealing with lower-level syscalls directly), and is harder to do
> > from a ROP chain (I'm not aware of this having been implemented yet - so
> > it sounds like fun and an appropriate challenge for you now). This
> > would be relevant both with and without LKRG.
>
> I don't think this challenge is acceptable for me as I strongly
> convinced that whole the art of exploit developing is always about
> to exploit the certain bug in certain number of environments.
I won't argue about art as that's a matter of taste (and besides I agree
that Andrey's exploit is a work of art and I like your extension of it),
but I will argue about craftsmanship:
> So it's more academic and have nothing to do with the real world.
I think you're very wrong. I think exploit portability and reliability
are both very important in the real world, and determine how many
systems actually get compromised. I think writing a more portable and
more reliable exploit corresponds to better craftsmanship.
This specific exploit is reliable, but not portable. That's room for
improvement.
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.
