Старый 14.07.2013, 10:28   #21
SynQ
 
Регистрация: 11.07.2010
Сообщений: 950
Репутация: 351
По умолчанию

В 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 вне форума   Ответить с цитированием
Старый 18.11.2013, 10:58   #22
SynQ
 
Регистрация: 11.07.2010
Сообщений: 950
Репутация: 351
По умолчанию

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; 21.11.2013 в 09:36..
SynQ вне форума   Ответить с цитированием
Старый 04.12.2013, 09:40   #23
SynQ
 
Регистрация: 11.07.2010
Сообщений: 950
Репутация: 351
По умолчанию

Еще один способ выполнять код в ядре имея права root (на случай отключенных/подписанных модулей ядра) - через сисколл kexec:
http://mjg59.dreamwidth.org/28746.html
SynQ вне форума   Ответить с цитированием
Старый 30.01.2014, 10:31   #24
SynQ
 
Регистрация: 11.07.2010
Сообщений: 950
Репутация: 351
По умолчанию

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

http://git.kernel.org/cgit/linux/ker...6f5127828eb79d
SynQ вне форума   Ответить с цитированием
Старый 02.02.2014, 19:52   #25
suv121
 
Регистрация: 19.12.2013
Сообщений: 3
Репутация: 0
По умолчанию

а может кто нибудь рассказать про загрузку модулей ядра, когда ядро скомпилировано без поддержки LKM? и можно ли подменять системные вызовы с пользовательского уровня?
suv121 вне форума   Ответить с цитированием
Старый 30.05.2014, 11:01   #26
SynQ
 
Регистрация: 11.07.2010
Сообщений: 950
Репутация: 351
По умолчанию

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

Обзор: http://lwn.net/Articles/599231/
SynQ вне форума   Ответить с цитированием
Старый 05.06.2014, 13:33   #27
SynQ
 
Регистрация: 11.07.2010
Сообщений: 950
Репутация: 351
По умолчанию

Важное изменение в 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 вне форума   Ответить с цитированием
Старый 16.10.2014, 10:44   #28
SynQ
 
Регистрация: 11.07.2010
Сообщений: 950
Репутация: 351
По умолчанию

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 вне форума   Ответить с цитированием
Старый 27.11.2014, 10:12   #29
SynQ
 
Регистрация: 11.07.2010
Сообщений: 950
Репутация: 351
По умолчанию

CSAW CTF 2014 Linux kernel exploitation challenge & solution.
https://github.com/mncoppola/suckerusu
SynQ вне форума   Ответить с цитированием
Старый 17.02.2015, 14:32   #30
SynQ
 
Регистрация: 11.07.2010
Сообщений: 950
Репутация: 351
По умолчанию

Цитата:
@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
SynQ вне форума   Ответить с цитированием
Ответ

Метки
exploit, exploitdev, kernel, linux

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход



Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot