[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Nov 2018 02:18:23 +0400
From: Ilya Matveychikov <matvejchikov@...il.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: LKRG Exploit Detection bypass (LOL again)
> 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.
>
> 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. Except you want to keep LKRG
working well for synthetic tests like “loading a well-known bad written
publicly available github hosted r00tk1t”.
> Discussion on Twitter:
>
> https://twitter.com/cr0nym/status/1063368081530077184
> https://twitter.com/solardiz/status/1063782606779469824
>
Thanks for mention me on Twitter, tho :)
> 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 :)
>
> 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. So it’s
more academic and have nothing to do with the real world.
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.
