[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191207193406.GA19165@openwall.com>
Date: Sat, 7 Dec 2019 20:34:06 +0100
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: bug: LKRG kills VirtualBox host VMs
Hi Adam,
No problem discussing this on the list.
On Sat, Dec 07, 2019 at 07:10:13PM +0100, Adam Zabrocki wrote:
> On Sat, Dec 07, 2019 at 12:45:47PM +0100, Solar Designer wrote:
> > On Mon, Dec 02, 2019 at 07:00:44PM +0100, Adam Zabrocki wrote:
> > > #define P_LKRG_CI_X86_NO_MSR
> > > #define P_LKRG_PCFI_NO_STACKWALK
> > >
> > > and recompile LKRG.
> >
> > VirtualBox is pretty common, and the above is obscure. We need to at
> > least document this prominently, or better yet introduce a module option
> > to enable VirtualBox compatibility in an existing build of LKRG, so that
> > a rebuild would not be necessary.
>
> I understand that VBox is common. However, the logic which they have is very
> nasty. I understand that's not an excuse for LKRG to not support it. That's why
> I've analyzed what could be the possibilities to deal with it. The reason why I
> went into the way of the different compilation definition is because of the
> security. Both of that options implies weaker security validation affecting
> both CI as well as ED. In case of CI from weird reasons VBox set to NULL most
> of the MSRs (bot not IDT). However, I can deal with that. Nevertheless in case
> of ED it requires NOT to do stack walk/validation. That's pretty significant
> relax of ED / pCFI validation. That validation is pretty effective in catching
> various SMEP bypasses. If we make it option (relax of stack validation) then
> attacker could 'flip' our internal flag very easily (since it would need to be
> kept as a global variable). The way how we have it now, there is no way to
> relax such validation in a dynamic way.
> I would really prefer to keep it how it is and find some clear way of
> documention it. However, don't know what would be the best way of doing it.
> Maybe do you have something in your mind?
Of course, we need to document that enabling of VirtualBox compatibility
reduces LKRG's security.
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.
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.
