[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190221024109.GA2869@pi3.com.pl>
Date: Thu, 21 Feb 2019 03:41:09 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: Re: LKRG 6.0 Exploit Detection bypass
Hi,
At the beginning I would like to thank you for looking and evaluating new
version of LKRG! The more eyes, the more problems can be discovered and
fixed, so thanks again ;-)
I've spent some time on what you've researched. Here a are couple of notes:
- Before we published LKRG 0.6 Alexander suggested a feature to panic() the
kernel in case of SMEP violation if lkrg.ci_panic=1. I thought it is not
needed for now since new version of LKRG has tons of new code which requires
testing. This means I might have overlooked something in case of SMEP strict
rules which would result in some incompatibility issues. Nevertheless, I
haven't seen one, and I believe it could be a good mitigation for various
variants of bypasses.
- All versions of the bypasses are detected by LKRG via detection of SMEP
violation, nevertheless only 2 of the variants are being blocked:
a. variants (1) and (2) are blocked
b. variants (3) and (4) are correctly detected but not blocked:
I. variant (3) just detected
II. variant (4) detected but also Proof Of Concept process is being
killed. Nevertheless, SIGKILL is delivered to the process which does
exploitation, but UMH was injected into the queue of kernel threads (that's
how UMH works) so even though exploit is being killed, UMH continues to run
in parallel.
c. variant (5) is additionally detected by Runtime CI (hash doesn't
match).
so it looks like variant (3) is the most problematic one.
I went one step ahead and:
1. I'm introducing a new LKRG sysctl interface lkrg.smep_panic which will be
enabled by default. If LKRG detects SMEP violation it will kill the kernel
(invoke function panic()). This mitigation should be enough to stop bypasses
but it is only effective on machines which support SMEP
2. Additionally, I'm introducing a new LKRG sysctl interface lkrg.umh_lock
which will be disabled by default. If it is enabled, LKRG completely locks down
UMH functionality, and nothing can be executed via this interface. It has of
course side effects e.g. systemd daemon is using UMH to invoke
"systemd-cgroups-agent". If you enable lkrg.umh_lock then any call to the
systemd-cgroups-agent will fail. However, not all systems are using systemd.
Additionally, if you're super paranoid this feature can be useful for you.
3. For (3) I've also done some research and:
a. I've placed extra hook on "__queue_work" function where I only do SMEP
and WP bit verification. I send SIGKILL to any task which enters this function
when SMEP/WP is disabled and I do reenable them again.
b. I've placed extra hook on "lookup_fast" function where I do the same
check as for "__queue_work" + additionally I'm verifying just SP pointer (don't
do stack walk like full pCFI does).
it correctly stops (3) as well.
4. I've added SMEP and WP bits validation every time, when ED verification is
being executed and whenever inode is being marked as dirty.
Everything what I mentioned here is a relatively new code, and requires some
more testing. I've tested it but it needs more verification in the various
environment / kernels.
It is worth to point out that we might decide to cut / add or modify some of
the features mentioned here. Until we release a new official and stable version
of LKRG, I think that changes might be available to the community and I would
be thankful if more people test them.
These changes are available in the official LKRG repo here:
https://bitbucket.org/Adam_pi3/lkrg-main/src
Thanks,
Adam
On Thu, Feb 21, 2019 at 04:02:48AM +0400, Ilya Matveychikov wrote:
> One more ED bypass:
> - (5) LKRG ED bypass by disabling kprobes (patching the kernel)
>
> https://github.com/milabs/kernel-exploits/commit/a19d1d80e3e1fe10da6ccc6f5c296a94912e506b
>
>
> > On Feb 20, 2019, at 9:43 AM, Ilya Matveychikov <matvejchikov@...il.com> wrote:
> >
> > Hello,
> >
> > I’d like to show few more exploit detection bypass techniques:
> > https://github.com/milabs/kernel-exploits/commit/6bd99d97c3f99a0a743a012b9cb90fb2fe1c0970
> >
> > By this commit we have the list of following:
> > - (1) LKRG ED bypass using UMH and chmod + chwon, the very first bypass
> > - (2) LKRG ED bypass by owerwriting inode->i_{uid,gid,mode} using simple_setattr()
> > - (3) LKRG ED bypass by owerwriting inode->i_{uid,gid,mode} directly
> > - (4) LKRG ED bypass by unlocking "UMH lock down" with LD_PRELOAD
> > - LKRG "poor man's CFI" bypass
> >
> > (1) and (2) were introduced few months before.
> >
> > (3) is the improvement of (2) which uses DKOM technique to manipulate inode
> > directly without being detected by simple_setattr() hook.
> >
> > (4) is the bypass of "UMH locking by using whitelist of programs" which basically
> > allows one to use LD_PRELOAD to inject his payload to /sbin/modprobe or similar.
> >
> > Since the use of (3) and (4) is locked by pCFI (poor man's Control Flow Integrity)
> > mitigation introduced in LKRG 6.0 I had to add the “rich man’s CFI bypass” which
> > wraps calls to all of the listed bypasses with 2 macros which are actually fakes
> > the call stack for the time of exploitation so LKRG could not see this.
> >
> > Ilya
> >
>
--
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.
