[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Nov 2018 16:51:18 +0100
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: LKRG 0.5
On Mon, Nov 12, 2018 at 05:25:02PM +0400, Ilya Matveychikov wrote:
> I've seen the announcement and updated to latest sources just
> to record a video :)
You're quick. :-)
> I'm terrible sorry but I'm pretty sure no one use it
There's some use, but not a lot.
Personally, I don't (co-)administer a lot of systems where LKRG would be
suitable. On most, we're trying not to leave unfixed known critical
vulnerabilities. However, I did load LKRG on one system (that's
actually in use, not just testing), which for some subtle reasons (need
weird/old drivers, and too lazy to update those along with the kernel
anyway) runs a kernel with known critical vulnerabilities. Of course,
this is still a high risk, but maybe LKRG makes it just a bit lower -
against casual rather than determined attackers. I guess others may
have similar occasional uses, too. And as LKRG matures, maybe it'll be
useful for hosting providers, etc. as well, where the provider is not
certain to install updates in time.
> and it'll never be a part of upstream
Sure. We don't intend to ever upstream it. That would go against the
"security through diversity" concept.
> in the way how it's implemented now.
Unrelated to upstreaming, which I think we're in agreement(?) shouldn't
happen anyway, do you have any specific "complaints"/suggestions on the
implementation? Besides the Makefile patch you had posted?
I have my own "complaints" - plenty of those - which we're discussing
with Adam privately. To summarize, in my opinion, LKRG tries to do too
much - more than is needed against exploits that do not specifically
target LKRG, while at the same time not enough against determined
attackers nor against eventual exploits and rootkits that target LKRG
(and we'll have to be making changes if those tools become widespread,
anyway). I question the value of all of "CI" features of LKRG - to me,
an "ED" only LKRG would make sense, and would still fall in the same
category of "security through diversity" against most existing exploits.
I haven't looked into the bug you triggered, but it's clearly part of
"CI" (and apparently that's what you tried to bypass, and, as you say,
would have bypassed).
That's just my opinion, which I don't feel strongly about, and as you
can see Openwall is happy to be the umbrella for Adam's LKRG as it is
anyway. We'll see where this leads us. Maybe "CI" will become
optional. Maybe "CI" will become so polished and extensive that it's
robust and the probability of a successful bypass by (rather than kernel
panic on an attempted bypass, which is a win for LKRG) by LKRG-targeting
tools on a production system becomes low (or at least far from certain).
Maybe "CI" will become hypervisor-based.
"CI" being lower-level magic (than "ED") also makes it valuable on its
own, in terms of hack value. I understand that/why Adam likes to play
with it. I hope authors of LKRG bypasses will similarly enjoy the game.
Do you? :-) (Un)fortunately, this is also complicated and error-prone,
for both sides.
I also have "complaints" on coding style; Adam agrees with some of
those, but we both realize that changing the coding style for the
existing LKRG project is significant effort. I am particularly unhappy
about the code duplication inside LKRG - while some of it helps logical
separation of the different hooks, etc., some other does not (is just
sloppy, and needs work). We're discussing that privately, too.
> > Are you saying you have an LKRG bypass PoC ready and working, and it
> > only "failed" like this when you wanted to record a video?
>
> Exactly.
Great. It'd be helpful to know more - ideally, have a copy of your code
and/or a kernel crash dump - but it's your call.
In general, not only are bypasses expected, but unintended kernel
modifications (which assume you've already compromised system security
through a vulnerability, or "abused" legitimate root access) may result
in kernel crashes like what you observed. That said, the particular
crash does look like a fixable LKRG bug, and I guess Adam will look into
it and fix it.
Is the khook_demo module you have loaded part of what you call a LKRG
bypass, or is it some unrelated demo/test you ran? Is it part of what
caused the crash?
If it's part of the bypass, then that wouldn't count per our threat
model unless you loaded the module while under illegitimate root access
obtained via a kernel vulnerability exploit (in which case "ED" is meant
to trigger on module loading attempt). Simple loading of kernel modules
(including custom ones) as legitimate root is allowed under LKRG -
including modules that would substantially modify system behavior (e.g.,
hook functions).
The "experimental" branch of LKRG may be configured to disallow that,
but I also question its value - which is part of why this isn't in LKRG
"main". That's what I called "*BSD securelevel on steroids" in private
discussions with Adam. That approach works - making root not entirely
powerful - but is hard, distro-specific, and time-consuming to
reasonably use in practice. I did use securelevel on Linux 2.0 in 1998
or so, and got patches into upstream Linux 2.0.x branch to make
enforcing that possible, but such use was either tricky or incomplete.
Then securelevel got replaced with cap-bound in Linux 2.2. Then
dropped. We could re-introduce it in LKRG, and Adam did in
"experimental" and in a way that's easier to use (due to password
authentication to the kernel to temporarily disable this protection when
needed). I'd expect very few of LKRG users to use this functionality
where it's appropriate and correctly, but if that's what you wanted,
feel free to try "experimental".
Now this is probably more than you wanted to know. ;-) But even if so,
maybe others in here will find this discussion useful.
Thanks again,
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.
