[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191207181013.GA31576@pi3.com.pl>
Date: Sat, 7 Dec 2019 19:10:13 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: bug: LKRG kills VirtualBox host VMs
[- lkrg-users list]
Hi Alexander,
I've removed mailing list for now.
On Sat, Dec 07, 2019 at 12:45:47PM +0100, Solar Designer wrote:
> Hi Adam,
>
> On Mon, Dec 02, 2019 at 07:00:44PM +0100, Adam Zabrocki wrote:
> > This is a 'hacky' feature and it's violating some of the integrity rules which
> > LKRG's ED feature enforces. However, I've introduced 2 compilation options
> > which can relax some of the validation in LKRG and allows such a nasty
> > functionality. They are DISABLED by default but if you really want you can
> > enable it and compile LKRG with them. If you do so, you might run LKRG and
> > VirtualBox together. To do that you should edit "src/p_lkrg_main.h" file and
> > uncomment following definitions:
> >
> > #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?
Thanks,
Adam
> Thanks,
>
> Alexander
--
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.
