Follow @Openwall on Twitter for new release announcements and other news
[<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.