Заметка про task_struct в ядре Linux.

[SynQ]

В 3.11 меняется file_operations, наверно скажется на руткитах, хукающих readdir():

There is a new struct file_operations method:

int (*iterate) (struct file *, struct dir_context *);

Its job is to iterate through the contents of a directory. This method is meant to serve as a replacement for the readdir() method that eliminates persistent race conditions associated with updating the current read position. All internal users have been converted, and the readdir() method has been removed.

http://git.kernel.org/cgit/linux/ker...71110e629bb900

[SynQ]

CSAW2013 CTF write-up про задание с exploitation в ядре:
https://github.com/acama/ctf-writeup...rad%20Oberberg

write-up от автора задания: http://poppopret.org/2013/11/20/csaw...ion-challenge/

[SynQ]

Еще один способ выполнять код в ядре имея права root (на случай отключенных/подписанных модулей ядра) - через сисколл kexec:
http://mjg59.dreamwidth.org/28746.html

[SynQ]

Пока идет революция на Майдане, в ядре тоже революция. Патч Кейса Кука для KASLR приняли в апстрим. Ядерная рандомизация будет в 3.14.
Т.к. она ломает гибернацию и perf, то вероятно дистрибутивы пока не будут включать эту опцию.

http://git.kernel.org/cgit/linux/ker...6f5127828eb79d

[suv121]

а может кто нибудь рассказать про загрузку модулей ядра, когда ядро скомпилировано без поддержки LKM? и можно ли подменять системные вызовы с пользовательского уровня?

[SynQ]

Набор заданий для тех, кто хочет разобраться в устройстве ядра Linux: http://eudyptula-challenge.org/

Обзор: http://lwn.net/Articles/599231/

[SynQ]

Важное изменение в 3.15 на x86_64 - размер ядерного стека приложений увеличен в 2 раза (с 8192 до 16384).

коммит

+++ b/arch/x86/include/asm/page_64_types.h
@@ -1,7 +1,7 @@
#ifndef _ASM_X86_PAGE_64_DEFS_H
#define _ASM_X86_PAGE_64_DEFS_H
-#define THREAD_SIZE_ORDER 1
+#define THREAD_SIZE_ORDER 2
#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)
#define CURRENT_MASK (~(THREAD_SIZE - 1))

Соотв-но меняется формула получения адреса thread_info из текущего значений стека (см. саму статью на 1-ой странице темы).

[SynQ]

https://plus.google.com/+MathiasKrau...ts/daRPLr3Di6a

В 3.18 внедрили slab merging в SLAB так же, как это было ранее в SLUB (теперь будет проще эксплуатировать heap overflow и UaF):

The upcoming Linux kernel v3.18 will extend the slab merging feature of the SLUB allocator to the SLAB allocator (see, e.g., https://git.kernel.org/linus/423c929cbb and https://git.kernel.org/linus/12220dea07).

Lets see what that feature does by slightly instrumenting the kernel (the same information is available via sysfs but a printk() is more simple to grep for ...

[vanilla]$ git diff -- mm/slub.c
diff --git a/mm/slub.c b/mm/slub.c
index 3e8afcc07a76..650fbef4510c 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@-3699,6+3699,7 @@ __kmem_cache_alias(const char *name, size_t size, size_t align,
int i;
struct kmem_cache *c;

+ pr_info(">>> %s: merging '%s' into '%s'\n", _func_, name, s->name);
s->refcount++;

/*

This gives us the following:

[vanilla]$ dmesg | grep merging | grep kmalloc
[ 0.013565] >>> __kmem_cache_alias: merging 'pid' into 'kmalloc-128'
[ 0.014213] >>> __kmem_cache_alias: merging 'anon_vma_chain' into 'kmalloc-64'
[ 0.220085] >>> __kmem_cache_alias: merging 'cred_jar' into 'kmalloc-192'
[ 0.220891] >>> __kmem_cache_alias: merging 'task_xstate' into 'kmalloc-512'
[ 0.221653] >>> __kmem_cache_alias: merging 'fs_cache' into 'kmalloc-128'
[ 0.223107] >>> __kmem_cache_alias: merging 'key_jar' into 'kmalloc-256'
[ 0.223828] >>> __kmem_cache_alias: merging 'names_cache' into 'kmalloc-4096'
[ 0.296000] >>> __kmem_cache_alias: merging 'pool_workqueue' into 'kmalloc-256'
[ 0.298417] >>> __kmem_cache_alias: merging 'skbuff_head_cache' into 'kmalloc-256'
[ 0.302642] >>> __kmem_cache_alias: merging 'uid_cache' into 'kmalloc-128'
[ 0.304361] >>> __kmem_cache_alias: merging 'bio_integrity_payload' into 'kmalloc-192'
[ 0.305139] >>> __kmem_cache_alias: merging 'biovec-16' into 'kmalloc-256'
[ 0.305803] >>> __kmem_cache_alias: merging 'biovec-64' into 'kmalloc-1024'
[ 0.306483] >>> __kmem_cache_alias: merging 'biovec-128' into 'kmalloc-2048'
[ 0.307166] >>> __kmem_cache_alias: merging 'biovec-256' into 'kmalloc-4096'
[ 0.307846] >>> __kmem_cache_alias: merging 'bio-0' into 'kmalloc-192'
[ 0.349950] >>> __kmem_cache_alias: merging 'sgpool-8' into 'kmalloc-256'
[ 0.350622] >>> __kmem_cache_alias: merging 'sgpool-16' into 'kmalloc-512'
[ 0.351295] >>> __kmem_cache_alias: merging 'sgpool-32' into 'kmalloc-1024'
[ 0.352003] >>> __kmem_cache_alias: merging 'sgpool-64' into 'kmalloc-2048'
[ 0.352685] >>> __kmem_cache_alias: merging 'sgpool-128' into 'kmalloc-4096'
[ 0.362359] >>> __kmem_cache_alias: merging 'eventpoll_epi' into 'kmalloc-128'
[ 0.379876] >>> __kmem_cache_alias: merging 'request_sock_TCP' into 'kmalloc-256'
[ 0.380644] >>> __kmem_cache_alias: merging 'RAW' into 'kmalloc-1024'
[ 0.381277] >>> __kmem_cache_alias: merging 'PING' into 'kmalloc-1024'
[ 0.382419] >>> __kmem_cache_alias: merging 'ip_dst_cache' into 'kmalloc-192'
[ 0.384757] >>> __kmem_cache_alias: merging 'secpath_cache' into 'kmalloc-64'
[ 0.385472] >>> __kmem_cache_alias: merging 'inet_peer_cache' into 'kmalloc-192'
[ 0.386210] >>> __kmem_cache_alias: merging 'tcp_bind_bucket' into 'kmalloc-64'
[ 0.617272] >>> __kmem_cache_alias: merging 'fasync_cache' into 'kmalloc-64'
[ 0.618706] >>> __kmem_cache_alias: merging 'dnotify_struct' into 'kmalloc-32'
[ 0.620263] >>> __kmem_cache_alias: merging 'fsnotify_mark' into 'kmalloc-128'
[ 0.621750] >>> __kmem_cache_alias: merging 'kiocb' into 'kmalloc-128'
[ 0.706589] >>> __kmem_cache_alias: merging 'virtio_scsi_cmd' into 'kmalloc-192'
[ 0.708232] >>> __kmem_cache_alias: merging 'sd_ext_cdb' into 'kmalloc-32'
[ 0.710648] >>> __kmem_cache_alias: merging 'scsi_sense_cache' into 'kmalloc-128'
[ 0.731169] >>> __kmem_cache_alias: merging 'dm_io' into 'kmalloc-64'
[ 0.734164] >>> __kmem_cache_alias: merging 'io' into 'kmalloc-64'
[ 0.973911] >>> __kmem_cache_alias: merging 'request_sock_TCPv6' into 'kmalloc-256'
[ 0.982847] >>> __kmem_cache_alias: merging 'fib6_nodes' into 'kmalloc-64'

So the slab merging is pretty effective. But looking at what kind of caches get merged with the general purpose caches -- i.e. the kmalloc-* ones -- is kinda scary if you throw kernel bugs into the game. If one assumes some random driver contains a user triggerable use-after-free bug that just has the right size, that bug might be abused to tamper with critical kernel data structures like the process credentials ('cred_jar') or the process' memory mappings ('anon_vma_chain'). The other slab caches are probably "usable" too, e.g. the 'io' slab handles objects containing a function pointer making hijacking the kernel control flow easier.

This exploitation scenario is only possible encouraged by slab merging because the critical objects would be allocated from the same slab as the buggy driver's objects: the general purpose kmalloc slab. So, looking from a security angle, one may not want that slab merging feature. And, in fact, there's a knob to disable it: the kernel command line option "slub_nomerge" (or, starting with https://git.kernel.org/linus/12220dea07 "slab_nomerge"). This option disables the slab merging feature and therefore prevents the above exploitation scenario. It can be seen as a pro-active counter-measure as it enforces the creation of dedicated slabs. The use-after-free bug would still be there, but it couldn't be abused to manipulate the critical kernel objects -- as those would resist reside in a different slab cache.

So, lets have a look at what the PaX/grsecurity project has to say about that topic:

$ git diff v3.17..linux-grsec/v3.17-pax -- mm/slub.c
diff --git a/mm/slub.c b/mm/slub.c
index 3e8afcc07a76..74cd3bf90c8f 100644
--- a/mm/slub.c
+++ b/mm/slub.c
...
@@-2710,7+2718,7 @@ static int slub_min_objects;
* Merge control. If this is set then no merging of slab caches will occur.
* (Could be removed. This was introduced to pacify the merge skeptics.)
*/
-static int slub_nomerge;
+static int slub_nomerge = 1;

/*
* Calculate the order of allocation given an slab object size.


Cache merging disabled by default -- as expected

[SynQ]

CSAW CTF 2014 Linux kernel exploitation challenge & solution.
https://github.com/mncoppola/suckerusu

[SynQ]

@grsecurity: 2010: exploits target restart_block field of thread_info / 2015: upstream Linux finally does something about it

all arches, signal: move restart_block to struct task_struct
If an attacker can cause a controlled kernel stack overflow, overwriting the restart block is a very juicy exploit target. This is because the restart_block is held in the same memory allocation as the kernel stack. Moving the restart block to struct task_struct prevents this exploit by making the restart_block harder to locate.

https://git.kernel.org/cgit/linux/ke...b572c2cdbb2a24