[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4d108a5c-8c05-9fce-c5a9-060e14dda002@riseup.net>
Date: Sat, 7 Dec 2019 08:58:22 +0000
From: Patrick Schleizer <adrelanos@...eup.net>
To: lkrg-users@...ts.openwall.com
Subject: Re: bug: LKRG kills VirtualBox host VMs
Hi Adam!
This is amazing!
I'll plan on auto detecting if VirtualBox is already installed on the
host. And if so, opt-in these #define's.
Then LKRG will be VirtualBox compatible and ready for installation by
default in all distributions in all places (inside VMs and on the host)
that I maintain (Whonix, Kicksecure).
However, I need to wait for a signed git commit, signed git tag or
signed release [1] before I can test since I can't review the code and
wouldn't want to get surprised by a third party introducing a backdoor
(obfuscated C contest style [2]) during git fetch.
Kind regards,
Patrick
[1] https://www.openwall.com/lists/lkrg-users/2019/11/13/5
[2] https://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest
Adam Zabrocki:
> Hi,
>
> I've looked into that deeper. As I was expecting, VirtualBox has a feature
> which allows to dynamically allocate RWX page and execute code from there. In
> the past this feature was vulnerable to be exploited by the user and used in
> the wild to bypass signature enforcement for executing kernel code:
>
> https://www.virusbulletin.com/virusbulletin/2014/05/anatomy-turla-exploits/
>
> 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.
>
> Thanks,
> Adam
>
> On Tue, Nov 19, 2019 at 07:06:04AM +0100, Adam Zabrocki wrote:
>> Hi,
>>
>> Thanks for report. From what I can see LKRG is somehow right since during stack
>> walk it detected code which was executed from the page which doesn't belong to
>> any legally registered .text section (kernel core neither kernel module):
>>
>> Nov 18 08:30:59 debian kernel: 0xffffffffc106513b
>> Nov 18 08:30:59 debian kernel: 0xffffffffc1065428
>> Nov 18 08:30:59 debian kernel: 0xffffffffc108817d
>> Nov 18 08:30:59 debian kernel: 0xffffffffc1088c24
>>
>> However, it might be situation where VBox do some kind of JIT or any dynamic
>> code generation on dynamic page. I would be able to dig-in more when I set-up
>> repro environment for VirtualBox.
>> I can tell that I'm using VmWare and haven't seen problem under LKRG so far.
>>
>> Thanks,
>> Adam
>>
>> On Mon, Nov 18, 2019 at 06:58:00PM +0000, Patrick Schleizer wrote:
>>> Debian buster host. LKRG 0.7.
>>>
>>> This happened while VirtualBox 2 VMs were already running and installing
>>> LRKG.
>>>
>>> sudo dmesg | grep lkrg
>>> [ 336.576805] [p_lkrg] Loading LKRG...
>>> [ 337.126382] [p_lkrg] LKRG initialized successfully!
>>> [ 337.137161] [p_lkrg] <Exploit Detection> Not valid call - pCFI
>>> violation: process[EMT-2 | 2067] !!!
>>> [ 337.137164] [p_lkrg] <Exploit Detection> Frame[1] nr_entries[8]:
>>> [0xffffffffc106513b]. Full Stack:
>>> [ 337.137193] [p_lkrg] <Exploit Detection> Trying to kill process[EMT-2
>>> | 2067]!
>>> [ 337.137234] [p_lkrg] <Exploit Detection> Stack pointer corruption
>>> (ROP?) - pCFI violation: process[EMT-2 | 2067] !!!
>>> [ 337.137235] [p_lkrg] <Exploit Detection> Trying to kill process[EMT-2
>>> | 2067]!
>>> [ 337.485911] [p_lkrg] <Exploit Detection> Not valid call - pCFI
>>> violation: process[EMT-3 | 2116] !!!
>>> [ 337.485915] [p_lkrg] <Exploit Detection> Frame[1] nr_entries[8]:
>>> [0xffffffffc106513b]. Full Stack:
>>> [ 337.485959] [p_lkrg] <Exploit Detection> Trying to kill process[EMT-3
>>> | 2116]!
>>> [ 337.486014] [p_lkrg] <Exploit Detection> Stack pointer corruption
>>> (ROP?) - pCFI violation: process[EMT-3 | 2116] !!!
>>> [ 337.486016] [p_lkrg] <Exploit Detection> Trying to kill process[EMT-3
>>> | 2116]!
>>>
>>>
>>> This happened after reboot when trying start a VM:
>>>
>>> Nov 18 08:30:58 debian kernel: vboxdrv: 0000000000000000 VMMR0.r0
>>> Nov 18 08:30:59 debian kernel: vboxdrv: 0000000000000000 VBoxDDR0.r0
>>> Nov 18 08:30:59 debian kernel: vboxpci: created IOMMU domain
>>> 000000000278fc42
>>> Nov 18 08:30:59 debian kernel: [p_lkrg] <Exploit Detection> Not valid
>>> call - pCFI violation: process[EMT-1 | 5252] !!!
>>> Nov 18 08:30:59 debian kernel: [p_lkrg] <Exploit Detection> Frame[1]
>>> nr_entries[8]: [0xffffffffc106513b]. Full Stack:
>>> Nov 18 08:30:59 debian kernel: --- . ---
>>> Nov 18 08:30:59 debian kernel: schedule+0x1/0x80
>>> Nov 18 08:30:59 debian kernel: 0xffffffffc106513b
>>> Nov 18 08:30:59 debian kernel: 0xffffffffc1065428
>>> Nov 18 08:30:59 debian kernel: 0xffffffffc108817d
>>> Nov 18 08:30:59 debian kernel: 0xffffffffc1088c24
>>> Nov 18 08:30:59 debian kernel: supdrvIOCtl+0xca6/0x36a0 [vboxdrv]
>>> Nov 18 08:30:59 debian kernel: VBoxDrvLinuxIOCtl_6_0_14+0x15c/0x230
>>> [vboxdrv]
>>> Nov 18 08:30:59 debian kernel: do_vfs_ioctl+0xa4/0x630
>>> Nov 18 08:30:59 debian kernel: --- END ---
>>> Nov 18 08:30:59 debian kernel: [p_lkrg] <Exploit Detection> Trying to
>>> kill process[EMT-1 | 5252]!
>>> Nov 18 08:30:59 debian kernel: [p_lkrg] <Exploit Detection> Stack
>>> pointer corruption (ROP?) - pCFI violation: process[EMT-1 | 5252] !!!
>>> Nov 18 08:30:59 debian kernel: [p_lkrg] <Exploit Detection> Trying to
>>> kill process[EMT-1 | 5252]!
>>> Nov 18 08:30:59 debian kernel: vboxpci: freeing IOMMU domain
>>> 000000000278fc42
>>> Nov 18 08:31:08 debian kernel: [p_lkrg] System is clean!
>>> Nov 18 08:31:24 debian kernel: [p_lkrg] System is clean!
>>> Nov 18 08:31:28 debian kernel: [p_lkrg] System is clean!
>>> Nov 18 08:31:28 debian kernel: [p_lkrg] System is clean!
>>> Nov 18 08:31:39 debian kernel: [p_lkrg] System is clean!
>>>
>>> Kind regards,
>>> Patrick
>>
>> --
>> 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.
