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.