Loading

attack xv6

原文:https://nos-ae.github.io/posts/attack-xv6/

思路

被这个实验折磨了两天,可能是2024新出的一个实验内容,网上资料少,参考了一篇仅有的博客,吭哧吭哧分析出来了个大概吧...在此记录一下,以便帮助有需要的人。

attack xv6的ans只有几行代码,根据实验描述,大概能猜到是secret程序结束之后,attack程序复用了它的物理内存,然后读取之前写入内存中的密码。难点在于我们如何定位到那段内存。

在开始之前直接先给出ans,可以看到代码是很简单的:

#include "kernel/types.h"
#include "kernel/fcntl.h"
#include "user/user.h"
#include "kernel/riscv.h"

int
main(int argc, char *argv[])
{
  // your code here.  you should write the secret to fd 2 using write
  // (e.g., write(2, secret, 8)
  char *end = sbrk(17*PGSIZE);
  end += 16 * PGSIZE;
  write(2, end+32, 8);
  exit(1);
}

下面说说实验思路,实验目的是找到被复用的物理内存,而内核的物理内存使用栈式链表管理(kalloc.c),secret程序通过kalloc从栈顶取内存页来使用,程序结束后通过kfree将这些内存页放回栈顶。到attack运行的时候同样使用kalloc从栈顶取内存页,因此就给了attack复用物理内存的机会。

值得注意的是,secret分配内存时这些页的出栈顺序,不一定与attack分配内存时的出栈顺序相同,比如secret分配页的顺序为1,2,3,归还的顺序为2,3,1,那么此时栈顶到栈底的页分别为1,3,2,当attack来分配的时候,拿到页的顺序就是1,3,2。因此核心在于分析程序运行时物理内存页的分配以及回收顺序,才能知道attack应该到哪块内存中获取密码。

fork secret

我们从attacktest中的第一个fork开始分析。

image-20241218210711222

fork调用了allocproc来创建proc,allocproc中首次使用了kallocp->trapframe分配一页物理页。

image-20241218210834186

接着allocproc调用proc_pagetable创建页表,其中,先调用uvmcreate使用kalloc为根页表分配一页:

image-20241218211533731

然后为trampolinep->trapframe建立映射,这两页在最虚拟内存的最高地址处,处于同一个三级页目录(xv6使用sv39,即三级页表),因此又kalloc了两页,分别对应一页二级页表、一页三级页表:

image-20241218211559339

因此allocproc一共创建了4页(trapframe、三级页表)。

回到fork中,由于此时xv6的fork还没实现copy on write特性,因此需要把父进程用户内存中的内容(用户内存即stack、heap这些低地址内存,不包括trapframe、trampoline)使用uvmcopy全部复制到子进程中。此时父进程用户内存占用此时为4页,因此子进程也复制了这4页进来,由于这4页位于虚拟内存中的低地址,其二级三级页表与trapframe/trampoline的都不一样,所以还会创建两页分别用于二级三级页表,一共kalloc了4+2=6页(为什么是4页具体原因在后面分析exec时会揭晓)。

综上,fork一共分配了4+6=10页。

exec secret

然后就是执行exec

image-20241218212525915

exec的实现中,会使用proc_pagetable创建新的页表来替换旧页表(这个也好理解,因为exec目的就是替换整个程序镜像,相当于从头开始执行一个新的程序,之前程序的相关内容全部丢弃)。根据之前的分析,proc_pagetable会分配3页。

接着,exec遍历elf文件的program header,将所有LOAD段加载进内存中。具体是通过uvmalloc分配物理内存,loadseg将段加载进内存。xv6程序的elf文件包含两个LOAD段,data段和text段,可以通过readelf看一下:

image-20241218213350943

这两个段分别加载到虚拟内存的第0页和第1页中。同理,这两页属于低地址的用户内存,需要2页(二级页表、三级页表)+2页来分别存放这两个段。

接着,exec为用户栈分配内存:

image-20241218213731624

这里的USERSTACK值为1,因为xv6固定用户栈大小为一页,后面的+1多出的一页用于page guard,便于栈溢出的处理。另外栈是紧挨着data段和text段之后分配的,他们属于同一个三级页表,不需要额外分配页表,因此栈分配一共分配了2页

exec的最后,还调用了proc_freepagetable来释放旧页表和旧用户内存:

image-20241218214350688s'd's

其中的两个uvmunmap释放pte映射(避免后续uvmfree的时候意外释放trampoline和trapframe的物理内存),并不释放物理页,因为trampoline是整个操作系统共享的不需要释放,而trapframe是用户态和内核态转换时的用到的存储区域,十分重要,同样不会释放(关于trapframe和trampoline的详细说明可以查阅book-riscv)。最后的uvmfree则是释放旧页表占用的内存(5页)以及用户内存(4页),共9页。

综上,exec一共分配了3+4+2=9页,然后又释放了9页。

secret

然后就是执行secret程序了,使用了sbrk分配了32页内存,然后在第10页写入数据。

至此,经过forkexecsbrk之后,secret程序一共占用了10+32=42页

wait secret

attacktest程序调用wait(0),获取到secret的proc,调用freeproc释放其内存:

image-20241218215540939

下面我们重点关注释放内存的顺序,即文章开头思路中说到的kfree“入栈”。

image-20241218215720587

首先是释放一页trapframe。然后进入proc_freepagetable中的uvmfree

image-20241218215822928

先调用uvmunmap从低到高地址释放用户内存,根据之前内存分配的分析,释放顺序为data段+text段、用户栈+page guard、32页堆内存(每页从低地址页到高地址页依次释放/入栈),共36页

最后释放页表,共5页

此时我们可以知道,kmem维护的空闲链表栈,从栈顶开始的页依次为:5页页表、第32页堆内存、第31页堆内存、...、第10页堆内存(密码所在的页)、...、第1页堆内存、page guard.....

attack

attacktest运行attack的方式和运行secret的一样,都是通过fork+exec,直接拿前面的分析结果,我们知道在开始执行attack程序之前,fork分了配10页,exec分配9页又释放了9页,其中fork分配的10页来自于5页页表、第32 ~ 28页堆内存,exec分配的9页来自第27 ~ 19页堆内存,后面又释放了9页回栈顶(因为我们要的第10页堆内存还在下面,所以我们不用关心这9页分别是什么),此时栈顶开始的页依次为:9页、第18页堆内存、...、第10页堆内存、...,通过用手指头数一下发现,我们只需要分配17页,密码就在最后一页中。

参考

https://blog.csdn.net/weixin_42543071/article/details/143351746

posted @ 2024-12-18 22:21  NOSAE  阅读(3)  评论(0编辑  收藏  举报