[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181113043309.GC28677@pi3.com.pl>
Date: Tue, 13 Nov 2018 05:33:09 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Cc: announce@...ts.openwall.com
Subject: Re: LKRG 0.5
Hi,
I was able to repro this NULL deref (thanks for this test!) and I've fixed
it via this commit:
https://bitbucket.org/Adam_pi3/lkrg-main/commits/7c9b79bea77df2dc4944b0fe29f4dc8c3d26b302
In short it happens because of the malicious activity of khook_demo module.
This module hooks "inode_permission" function (kernel core .text section) and
redirects to the internal function "khook_inode_permission" inside of the
khook_demo module.
Hook is being done in a very smart way by modifying long NOP (injected by
*_JUMP_LABEL) to JMP instruction (emulating *_JUMP_LABEL functionality). LKRG
correctly detects not-legit modification but new code has a bug that if
modification happens to the core kernel .text from the 3rd party module,
and falls perfectly into *_JUMP_LABEL scenario, it detect this bad
behaviour but then might generate NULL deref.
Thanks for testing it. Now LKRG detects not-legit hook and do not crash the
kernel (unless you enable lkrg.ci_panic=1 via sysctl).
*_JUMP_LABEL support in LKRG is already complicated and will be rewritten in
the future versions - but it will be bigger change which requires some time to
research.
Thanks,
Adam
On Mon, Nov 12, 2018 at 04:40:31PM +0400, Ilya Matveychikov wrote:
> Hey,
>
> While recoding a video of LKRG 5.0 bypass I faced a BUG. So, no video at this time
> but maybe next time when this bug will be fixed :-)
>
> [110338.513153] BUG: unable to handle kernel NULL pointer dereference at (null)
> [110338.963680] IP: [<ffffffffc0638c89>] p_cmp_bytes+0x239/0x940 [p_lkrg]
> [110339.482601] PGD 0
> [110339.546025] Oops: 0000 [#1] SMP
> [110339.606575] Modules linked in: khook_demo(OE) p_lkrg(OE) ufs msdos xfs vboxsf(OE) isofs ppdev binfmt_misc input_leds serio_raw parport_pc video parport vboxguest(OE) ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul vboxvideo(OE) ghash_clmulni_intel drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops aesni_intel ttm mptspi aes_x86_64 lrw glue_helper ablk_helper cryptd scsi_transport_spi mptscsih drm psmouse e1000 mptbase
> [110343.097907] CPU: 1 PID: 3858 Comm: kworker/u8:2 Tainted: G OE 4.8.0-53-generic #56~16.04.1-Ubuntu
> [110343.559133] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
> [110343.947920] Workqueue: events_unbound p_check_integrity [p_lkrg]
> [110343.997952] task: ffff9d7a7aa8d880 task.stack: ffff9d7a69cd4000
> [110344.778608] RIP: 0010:[<ffffffffc0638c89>] [<ffffffffc0638c89>] p_cmp_bytes+0x239/0x940 [p_lkrg]
> [110345.086806] RSP: 0018:ffff9d7a69cd7a10 EFLAGS: 00010086
> [110345.531187] RAX: 0000000000000000 RBX: ffffffffc00992e0 RCX: 0000000000000022
> [110345.947264] RDX: 0000000000000000 RSI: 0000000000004000 RDI: ffffffffc00992e0
> [110345.982935] RBP: ffff9d7a69cd7d70 R08: 0000000000000000 R09: 0000000000000190
> [110346.415325] R10: ffffc06fc1735898 R11: ffffffffc009b100 R12: ffffc06fc0c01000
> [110346.960013] R13: 0000000000293898 R14: ffff9d7a69cd7c51 R15: ffffc06fc0e94898
> [110347.167329] FS: 0000000000000000(0000) GS:ffff9d7a7fc80000(0000) knlGS:0000000000000000
> [110347.558976] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [110347.587279] CR2: 0000000000000000 CR3: 000000003a9ad000 CR4: 00000000000406e0
> [110347.842746] Stack:
> [110347.962880] ffff9d7a7bb95980 ffff9d7a69cd7a50 0000000000000000 ffffffff992002b8
> [110348.742840] ffffffff99493b50 0000000000293899 ffffc06fc0e94899 0000000000000022
> [110349.267536] 000000000089f697 ffffc06fc1735898 000000000000000f ffffc06fc14a2000
> [110349.564549] Call Trace:
> [110349.571774] [<ffffffff992002b8>] ? 0xffffffff992002b8
> [110349.931856] [<ffffffff99493b50>] ? writenote+0xc0/0xc0
> [110349.967838] [<ffffffffc06395a2>] p_check_integrity+0x212/0x1980 [p_lkrg]
> [110350.058749] [<ffffffff992c1451>] ? pick_next_task_fair+0x111/0x4f0
> [110351.175217] [<ffffffff9929d89b>] process_one_work+0x16b/0x4a0
> [110351.551869] [<ffffffff9929dc1b>] worker_thread+0x4b/0x500
> [110351.567748] [<ffffffff9929dbd0>] ? process_one_work+0x4a0/0x4a0
> [110351.595704] [<ffffffff9929dbd0>] ? process_one_work+0x4a0/0x4a0
> [110351.623514] [<ffffffff992a3fb8>] kthread+0xd8/0xf0
> [110351.659862] [<ffffffff99a9aa9f>] ret_from_fork+0x1f/0x40
> [110351.673789] [<ffffffff992a3ee0>] ? kthread_create_on_node+0x1e0/0x1e0
> [110351.683488] Code: ff 0f 87 d3 06 00 00 48 8b 8d d8 fc ff ff 48 39 8d f0 fc ff ff 0f 84 1c 05 00 00 4d 85 db 0f 84 b4 04 00 00 48 8b 85 b0 fc ff ff <4c> 3b 18 0f 85 ad 03 00 00 0f b6 85 03 fd ff ff 48 8d 95 03 fd
> [110351.727548] RIP [<ffffffffc0638c89>] p_cmp_bytes+0x239/0x940 [p_lkrg]
> [110351.729925] RSP <ffff9d7a69cd7a10>
> [110351.731103] CR2: 0000000000000000
>
>
> > On Nov 12, 2018, at 4:27 PM, Solar Designer <solar@...nwall.com> wrote:
> >
> > Hi,
> >
> > We'd like to announce Linux Kernel Runtime Guard (LKRG) version 0.5:
> >
> > https://www.openwall.com/lkrg/
> >
> > The following changes have been made between LKRG 0.4 and 0.5:
> >
> > *) [CI] Add *_JUMP_LABEL support for kernel modules (a major change)
> > *) [CI] Add support for "cold" function versions generated by new GCC -
> > necessary to correctly handle *_JUMP_LABEL
> > *) [CI] Change output message format when *_JUMP_LABEL was detected for kernel
> > module's .text section
> > *) [CI] Add new sysctl interface - optional panic() on CI verification failure
> > *) [ED] Hook generic_permission() instead of may_open()
> > *) [ED] Hook and correctly handle override_creds() / revert_creds()
> > *) Add Mikhail Klementev's patches for Makefile, .gitignore and missing include
> >
> > Legend:
> > [CI] - Code Integrity
> > [ED] - Exploit Detection
> >
> > Like before, this release is mostly due to work by Adam 'pi3' Zabrocki.
> >
> > 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.
