[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200709192952.GA3068@openwall.com>
Date: Thu, 9 Jul 2020 21:29:52 +0200
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
Cc: KOLANICH <kolan_n@...l.ru>
Subject: Re: <Exploit Detection> UMH is executing file from memory on Ubuntu 20.04
Hi,
I'd like to share my higher-level perspective in addition to the direct
answers Adam helpfully posted.
On Tue, Jul 07, 2020 at 10:32:26PM +0300, KOLANICH wrote:
> Today I have noticed `<Exploit Detection> UMH is executing file from memory` message on Ubuntu 20.04 during boot (may be a result of zswap being enabled (this was the first reboot after I have enabled zswap), but I haven't tried to verify that).
>
> 1. Can I make lkrg to dump the original binaries that are being loaded, i.e. by exposing them via a VFS, and other info about them, such as pids? Which fields of subprocess_info do I need for that?
> 2. Can it also generate stack traces, to identify the modules that load them, on kernels available in release builds of distros?
> 3. Why is execution of these processes not aborted, just a message logged, even without a mode to panic on it?
LKRG provides best effort protection against many common attacks on the
Linux kernel. LKRG isn't meant to enforce an arbitrary policy just for
the sake of it.
For LKRG, the example KOLANICH describes is a false positive. I think
it'd be wrong to complicate LKRG's code so that it'd report such false
positives in more detail (dump the binary from memory, etc.), nor so
that it'd block such uses of UMH unless those (are likely to) start to
be seen in attacks.
> 4. Also I dislike a bit the way the processes are whitelisted. Is it possible to whitelist the binaries by their hashes and hashes of their dependencies (a kind of Merkle tree)? Or maybe by public keys of digital signatures embedded into the binaries?
I see no reason to have LKRG verify hashes or signatures of the binaries
the kernel runs via UMH. If a system's userland is compromised such
that a known UMH binary pathname corresponds to a malicious binary, this
implies that the attacker already has root access. UMH doesn't provide
anything more than that - it does not provide ring 0 access.
It could make sense for the kernel to verify hashes or signatures of all
binaries and their dependencies, not only of those it runs via UMH.
However, this is not a task for LKRG, in part because LKRG isn't about
providing guarantees and enforcing a policy - it is about hopefully
thwarting common real-world attacks.
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.
