[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191209013417.GA17061@pi3.com.pl>
Date: Mon, 9 Dec 2019 02:34:17 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: bug: LKRG kills VirtualBox host VMs
Hi,
On Sun, Dec 08, 2019 at 12:58:34PM +0100, Solar Designer wrote:
> On Sun, Dec 08, 2019 at 06:36:40AM +0000, Patrick Schleizer wrote:
> > Solar Designer:
> > > As to your concerns on having an extra security-sensitive flag, we
> > > already have some other sysctl's that also affect LKRG in
> > > security-relevant ways. I think we need to come up with a common
> > > approach and framework for protecting all of those flags from easy
> > > one-shot overwrites or/and making such overwrites ineffective (read-only
> > > pages or/and checking against a keyed hash or redundant copies), and
> > > use it for all of LKRG's security-sensitive rarely-changing variables.
> > >
> > > Right now, LKRG's approach to these issues is inconsistent: some
> > > settings are security-sensitive yet runtime configurable, and some
> > > others are compile-time only. We need to make LKRG consistent.
> >
> > Maybe a single call "sudo sysctl -w lkrg.fuse=1" could make all LKRG
> > settings ready-only until reboot? Before that, all settings are read/write?
> >
> > I am also looking for a sysctl command to fuse all (not only LKRG)
> > sysctl settings, but I don't know if that would be overreaching LKRG's
> > scope. (Similar to linux "lockdown" feature.)
>
> Both of these suggestions seem reasonable on the surface, but I think
> are unreasonable once you dig deeper. Protecting the kernel from
> legitimate(*) root for real requires not only a lock-down of the kernel,
> but also of the userland, and a system like this becomes difficult to
> use and requires greater skill to use reasonably. Adam planned some
> lock-down features in the "experimental" branch of LKRG, but I oppose
> that direction because I expect only a negligible percentage of users
> will make reasonable use of those.
>
> (*) "Legitimate" as in "indistinguishable from legitimate by LKRG".
>
> What LKRG can reasonably do is protect its settings from attacks that
> are still in progress and haven't yet reached the point of having
> legitimate-looking root access. I suggested some ways to achieve that
> above. In that context, your suggestion for permanently locking down
> the settings makes sense for code simplification if it'd be the only
> mode we'd implement. It would also very slightly improve security
> through LKRG lacking gadgets (code snippets potentially reusable by an
> exploit's execution chain) that would unlock the settings, and which
> we'd have in there if one of my suggested approaches is implemented.
> However, we already have in LKRG some potential gadgets updating its
> existing databases. Randomization of kernel module load addresses (by
> the Linux kernel that LKRG is loaded into) should help prevent easy use
> of LKRG gadgets by exploits. We could also validate stack frames from
> within such gadgets.
>
> Alexander
I was thinking about some kind of "read only" pages for some time already. I
wanted to create a LKRG-owned RO page with all dynamically resolved addresses
and configuration options. Such page would be locked down and in case of rare
update similar approach to grsec/PaX would be performed (pax_open_kernel /
pax_close_kernel). Nevertheless, such approach is not perfect either since
attacker with the ability of corrupting PTEs could remove such protection.
However, if attacker has an ability to reliable modify PTE to whatever VA is
needed, LKRG can be bypassed anyway. Maybe I should come back to this topic
again.
To be able to protect from the attacks which can modify PTE, True-RO page owned
by more trust-level component (hypervisor/TZ) can be implement and I'm
researching this idea as well but it's more long-term plan.
For now I can focus on the original approach to "move" LKRG-owned variables to
the page which can be marked as RO. However, kernel doesn't support such
feature for the modules ("__read_only / __ro_after_init" work only for kernel
core). I need to spend some time to find good technical solution for that
problem (I would focus on dynamic creation LKRG-owned section since I don't see
any other good solution without pitfalls).
Thanks,
Adam
--
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.
