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.