[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191207182555.GA31952@pi3.com.pl>
Date: Sat, 7 Dec 2019 19:25:55 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: bug: LKRG kills VirtualBox host VMs
Ups... Please ignore it ;)
On Sat, Dec 07, 2019 at 07:10:13PM +0100, Adam Zabrocki wrote:
> [- 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
>
--
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.
