Golang版本简易fuzzer及debugger实践
2022-2-6 17:59:0 Author: mp.weixin.qq.com(查看原文) 阅读量:12 收藏


本文为看雪论坛精华文章
看雪论坛作者ID:LarryS

代码(https://github.com/zoemurmure/golearning/tree/main/fuzz)
 
本文为Fuzzing like a caveman(https://h0mbre.github.io/Fuzzing-Like-A-Caveman/)学习笔记,学习这个系列文章主要出于两个目的:一是为了学习fuzzing相关知识,二是为了学习go语言。因此文章中的代码使用go进行了改写。

基础的go版本mutation fuzzer

1.1.fuzz目标

https://github.com/mkttanabe/exif

1.2 fuzz方法

首先选取一个jpg格式的sample文件,从这里(https://github.com/ianare/exif-samples/tree/master/jpg)下载的Canon_40D.jpg。
 

然后分别采用bitflip和magic number替换的方式生成变形的用于测试的图片文件。其中为了保证文件的格式不变,需要排除掉文件开头的0xFFD8以及结尾的0xFFD9者四个字节。

由于go语言以及个人编程习惯的原因,采用的方法与原文有所差别:

(1)bitflip

该方法会随机选取所有字节中1%的字节,再随机选取其中的一位进行反转。

运用一点数学的知识,不使用原本文章中将字符串转换为数组再转回字符串的方式。

该函数完整代码如下:

// randomly change flipPercent of bytes in data// randomly flip one bit in every bytefunc bitFlip(data []byte) []byte {    result := make([]byte, len(data))    if nbytes := copy(result, data); nbytes == 0 {        panic("bitFlip: Error when copying")    }     nflips := int((float64(len(data)) - 4) * flipPercent)    var chosenIdx []int     for i := 0; i < nflips; i++ {        chosenIdx = append(chosenIdx, rand.Intn(len(data)-4)+2)    }     for _, x := range chosenIdx {        flipIdx := rand.Intn(8)        result[x] ^= byte(math.Pow(2, float64(flipIdx)))    }     return result}

(2)magic number

该方法源自GynvaelColdwind的‘Basics of fuzzing’ stream(https://www.youtube.com/watch?v=BrDujogxYSk&t=2545),将字节设置为特殊的,容易引发溢出的数值。这样如果程序中正好存在针对这几个字节的数值操作,就可能会发生溢出。

原文章的方法过于冗长,我直接把magic number做成一个二维数组,在通过随机的方式确定替换位置之后,搜索二维数组进行替换。

该函数完整代码如下:

// randomly overwrite 1~4 bytes in data with magic numberfunc magic(data []byte) []byte {    magicNum := [][]byte{        {0xFF}, {0x7F}, {0x00},        {0xFF, 0xFF}, {0x00, 0x00},        {0xFF, 0xFF, 0xFF, 0xFF},        {0x00, 0x00, 0x00, 0x00},        {0x80, 0x00, 0x00, 0x00},        {0x40, 0x00, 0x00, 0x00},        {0x7F, 0xFF, 0xFF, 0xFF},    }    result := make([]byte, len(data))    if nbytes := copy(result, data); nbytes == 0 {        panic("magic: Error when copying")    }     chosenIdx := rand.Intn(len(data)-8) + 2    chosenMagic := rand.Intn(len(magicNum))     for _, i := range magicNum[chosenMagic] {        result[chosenIdx] = byte(i)        chosenIdx++    }     return result}


1.3怎样抓取crash

编译生成可执行文件gcc -o exif sample_main.c exif.c,使用exec.Command执行命令并获得输出,利用panic, defer机制处理出现的错误,并将导致崩溃的图片保存在crashes目录下。

结果发现不管能不能成功,函数都会返回错误信息,然后所有测试图片都被保存到了crashes目录下。

查看源码发现,在sample_main.c文件中,main函数的返回值是由createIfdTableArray函数返回的result数值决定的,大于0表示程序处理的图片正常,小于0则是发生了错误,但无论result是何值,都表示程序正常识别出了图片中可能存在的错误并执行完成。

可是如果返回值不为0,系统会认为程序发生错误,因此我写的代码会认为所有图片都可以导致崩溃。

于是修改main函数,将返回值固定为0,然后再抓取出现的错误,进行1000次迭代后,找到了24个crash的图片。

该函数代码如下:

func exif(counter int, data []byte) {    defer func() {        handler := recover()        if handler != nil {            result := fmt.Sprintf("%v", handler)            fmt.Println(handler)            if strings.Contains(result, "Run cmd") {                filename := fmt.Sprintf("crashes/crash_%d.jpg", counter)                err := os.WriteFile(filename, data, 0644)                checkError("Write crash file", err)            }        }    }()     cmd := exec.Command("./exif.exe", "./mutated.jpg", "-verbose")     if _, err := cmd.CombinedOutput(); err != nil {        panic("Run cmd" + ": " + err.Error())    }}

上面代码在执行的时候可以看到遇到的错误返回值都是0xc0000005

1.4 crash分析

接下来使用Address Sanitizer分析crash,需要安装llvm,然后执行

clang .\exif.c .\sample_main.c -o exifsan.exe -g -fsanitize=address

如果出现Macro definition of vsnprintf conflicts with Standard Library function declaration的报错,需要删除exif.c中的#define vsnprintf _vsnprintf。

得到exifsan.exe之后,用它测试一下之前得到的crash图片:

PS D:\Myfiles\Code\go\src\fuzzer> .\exifsan.exe .\crashes\crash_103.jpg -verbosesystem: little-endian  data: little-endian===================================================================9344==ERROR: AddressSanitizer: access-violation on unknown address 0x000000000000 (pc 0x7ff6313c6a19 bp 0x00678fbbed20 sp 0x00678fbbcb00 T0)==9344==The signal is caused by a READ memory access.==9344==Hint: address points to the zero page.    #0 0x7ff6313c6a18 in parseIFD D:\Myfiles\Code\exif\exif.c:2448    #1 0x7ff6313c2434 in createIfdTableArray D:\Myfiles\Code\exif\exif.c:333    #2 0x7ff6313dd78e in main D:\Myfiles\Code\exif\sample_main.c:63    #3 0x7ff631424433 in invoke_main d:\a01\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78    #4 0x7ff631424433 in __scrt_common_main_seh d:\a01\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288    #5 0x7ffd898b7033  (C:\WINDOWS\System32\KERNEL32.DLL+0x180017033)    #6 0x7ffd8afe2650  (C:\WINDOWS\SYSTEM32\ntdll.dll+0x180052650) AddressSanitizer can not provide additional info.SUMMARY: AddressSanitizer: access-violation D:\Myfiles\Code\exif\exif.c:2448 in parseIFD==9344==ABORTING

确实可以得到具体的错误信息,之后我又多测试了几个文件,发现我遇到的大多都是access-violation on unknown address 0x000000000000,而不像文章中的那样有很多heap-buffer-overflow。

因为crash信息并不多,而且考虑到之后进一步学习可能还会用到这些信息,所以我在统计的时候没有像原文中那样对信息进行提取,而是全部输出到了一个文件中,方便后续使用。如果要提取的话,可能要用到正则表达式,这部分内容我不太确定,因为我的go语言学习还没有看到interface的部分,所以对于输出的处理可能会有想不到的地方。

至此,第一篇文章学习结束。

性能优化

2.1 简述

这里我尝试把bitflip中原本存在的nflips计算放到了循环外部,最终result计算中的乘方操作使用一个mask数组代替,然后像文章中一样全部使用bitflip执行1000次循环,性能优化了2秒左右。但是即使是这样运行时间也在15s~,我看了一下原文章中的性能,100,000迭代才执行了256s!!!

—>因为要fuzz新的目标,转战到kali上之后,效果提升了10倍,变成了1.5s,执行100,000次迭代,花费时间为86s。

2.2 新的fuzz目标——exiv2

在进行fuzz之前,我在此对代码进行了一些修改:

(1)尝试fuzz更多命令选项,使用map保存要fuzz的命令var cmds = []string{"rm", "pr", "fi", "fc", "ex"}

(2)统计输出的错误信息,只在该错误信息第一次出现的时候打印出来

func exif(counter int, data []byte, ccmd string) {    defer func() {        handler := recover()        if handler != nil {            result := fmt.Sprintf("%v", handler)            errorMessage[result]++            if errorMessage[result] == 1 {                fmt.Println(ccmd, result)            }            if !strings.Contains(result, "255") {                filename := fmt.Sprintf("crashes/crash_%d.jpg", counter)                err := os.WriteFile(filename, data, 0644)                checkError("Write crash file", err)            }        }    }()     cmd := exec.Command("exiv2", ccmd, "-v", "./mutated.jpg")     if err := cmd.Run(); err != nil {        panic("Run cmd" + ": " + err.Error())    }}

但是最终没发现什么bug。

code-coverage的重要性

3.1 修改bitflip函数

在这个系列文章中的第四篇,作者提到了bitflip和byte overwriting的区别:

如果只是随机反转字节中的一位,那个一个字节可以修改的数值只有8中可能,而修改字节则可以将其修改成其他任意的255个值。

因此重新写一个新的函数,不再采用随机反转字节中一位的方法,而是直接随机修改一个字节的值。

// randomly overwrite flipPercent of bytes in data// randomly choose from [0, 256)func byteOverwrite(data []byte) []byte {    result := make([]byte, len(data))    if nbytes := copy(result, data); nbytes == 0 {        panic("byteOverwrite: Error when copying")    }     var chosenIdx []int    for i := 0; i < nflips; i++ {        chosenIdx = append(chosenIdx, rand.Intn(len(data)-4)+2)    }     for _, x := range chosenIdx {        result[x] = byte(rand.Intn(256))    }     return result}


3.2 测试用漏洞程序

第四篇文章的其余部分使用一个示例漏洞程序说明了在fuzzer中引入code-coverage的重要性,改写后的go代码:

package main import (    "fmt"    "os"    "strconv") var checkPos = []float64{0.33, 0.5, 0.67}var checkVal = []byte{0x6c, 0x57, 0x21} func main() {    if len(os.Args) < 3 {        panic("usage vulfunc.exe filename ncheck ([0,3])")    }     data, err := os.ReadFile(os.Args[1])    if err != nil {        panic("main: error when reading file")    }     n := len(data)    nCheck, err := strconv.Atoi(os.Args[2])    if err != nil {        panic("main: error when convert string to number")    }     for i := 0; i < nCheck; i++ {        if checkFunc(data, int(checkPos[i]*float64(n)), checkVal[i]) {            fmt.Printf("[√]Check %d succeed!\n", i+1)        } else {            fmt.Printf("[x]Check %d failed!\n", i+1)            os.Exit(1)        }    }    vuln(data, n)} func checkFunc(data []byte, pos int, val byte) bool {    //fmt.Printf("%x\n", pos)    return data[pos] == val} func vuln(data []byte, n int) {    defer func() {        if handler := recover(); handler != nil {            fmt.Println("ERROR: index out of range [20] with length 20")            os.Exit(123)        }    }()     fmt.Println("[√]Pass all checks!")    newBuf := make([]byte, 20)     for i := 0; i < n; i++ {        newBuf[i] = data[i]    }}


3.3 测试结果

使用byteOverwrite方法,设置flipPercent值为0.02,迭代100,000次,漏洞程序只完成第一道检查,测试得到crash的图片8张;对比文章中1,000,000次迭代-88张图片的结果,两者的比例是一致的。

只做第一道检查,fuzz找到漏洞的概率≈8/100000=0.008%,如果想要通过两次检查,找到漏洞的概率成指数级下降,只有0.00000064%。

因此在不检查code-coverage的情况下,完全随机进行fuzz,能够找到漏洞的概率极小。

实现快照和代码覆盖率检查

4.1 代码整理

鉴于我最近对于go的熟练度有所提升,因此在学习文章内容之前,我先对之前自己写的代码进行了整理。把和实际的模糊测试工作有关的代码封装在了fuzzer包中,保留了SetConfig和Run接口(和go中的interface概念无关)。

最终外部的调用代码变成了这样:

func main() {    if len(os.Args) < 2 {        fmt.Println("Usage: fuzzer.exe <valid_jpg>")        os.Exit(1)    }     start := time.Now()     filename := os.Args[1]    data, err := os.ReadFile(filename)    if err != nil {        panic("main: " + err.Error())    }    // setconfig第二个参数表示测试方法,-1:随机,0:byteOverwrite,1:magic    fuzzer.SetConfig(100000, 0, []string{"./exif", "./mutated.jpg", "-verbose"})    fuzzer.Run(data)     duration := time.Since(start).Microseconds()    fmt.Println("Execution time:", duration, "ms")}

通过SetConfig设置迭代次数,模糊测试方法以及执行的命令,然后调用Run开始进行测试。

其中执行的命令那里封装的还不是特别好,mutated.jpg这个文件名还暴露在外面,因为之后的内容会放弃写入mutated.jpg文件,因此这部分内容还会有很大的变动,所以就没有解决这个问题。

4.2 性能分析

整理后的代码可以很清晰的看到整个模糊测试的流程:

每次迭代分为三个步骤:生成变形后数据,将变形数据写入文件,执行模糊测试。

因为在对目标程序进行模糊测试的时候,采用

ccmd := exec.Command(cmd[0], cmd[1:]...)

的方式执行命令,因此每次都需要把变形后的数据写入到文件,然后再由目标程序进行加载。上述流程在每次迭代都会发生,这也是文章中提到的导致性能下降的主要原因之一。

除此之外,文章中也提到了使用strace跟踪程序系统调用情况的方法,在使用strace检查我写的vulfunc的时候,在执行openat(AT_FDCWD, "./Canon_40D.jpg", O_RDONLY|O_CLOEXEC) = 3之前,程序执行了大量系统调用(有158行,出于篇幅考虑,不再贴出)。

因此文章中提到了利用调试器建立快照的方法。

4.3 调试器的实现

4.3.0 参考资料

原文提供了一篇关于ptrace的参考资料(④),同时我找到了一篇golang调试器的文章(③)。但是参考资料③是2017年写的,对于go这门新语言来说有些过时了,原本syscall包的功能已经被移植到了sys包中,因此我同时参考了delve(https://github.com/go-delve/delve)的源码。

4.3.1 流程 & 需要实现的内容

按照文章中的方法,需要实现一个调试器,使用调试器:

(1)在目标程序加载完图片以及结束之前设置断点(start, end)

(2)在程序到达start断点后:

  • 缓存此时可写内存段数据以及寄存器数据

  • 通过寄存器内容获得被加载图片所在内存地址

  • 将变形图片数据写入该地址

(3)继续执行程序,到达end断点

(4)恢复②中缓存的内存段数据以及寄存器数据

(5)返回②→c继续执行

因此这个调试器需要实现的功能有:暂停程序执行、设置和取消断点、读写内存、读写寄存器、继续执行程序。

4.3.2 暂停程序执行

这个功能的实现很简单,只需要将exec.Command的SysProcAttr属性中的Ptrace设置为true就可以:

cmd := exec.Command(s)cmd.SysProcAttr = &sys.SysProcAttr{Ptrace: true}

根据文档(https://pkg.go.dev/syscall#SysProcAttr),该操作相当于子进程执行了ptrace(PTRACE_TRACEME)。

4.3.3 读写寄存器

通过查找文档(https://pkg.go.dev/golang.org/x/sys/unix),找到了函数PtraceGetRegs(https://bbs.pediy.com/thread-271156.htm)

func PtraceGetRegs(pid int, regsout *PtraceRegs) error

测试读取RIP寄存器的值:

func Debug(s string, args []string) {    cmd := exec.Command(s, args...)    cmd.SysProcAttr = &sys.SysProcAttr{Ptrace: true}    if err := cmd.Start(); err != nil {        log.Fatal(err)    }     var regs sys.PtraceRegs    if err := sys.PtraceGetRegs(cmd.Process.Pid, &regs); err != nil {        log.Panic(err)    }    log.Printf("Value of rip: %x\n", regs.Rip)     err := cmd.Wait()    log.Printf("State: %v\n", err)}
func TestDebug(t *testing.T) {    Debug("./vulfunc", []string{"./Canon_40D.jpg", "3"})}

多次执行得到的RIP数值是一样的:

从IDA中检查vulfunc文件,可以看到地址0x45CB60就在程序开始的位置:

同理,如果需要写入寄存器,就使用函数PtraceSetRegs:

func PtraceSetRegs(pid int, regs *PtraceRegs) (err error)


4.3.4 读写内存

通过查找文档,找到函数PtracePeekData(https://bbs.pediy.com/thread-271156.htm)

func PtracePeekData(pid int, addr uintptr, out []byte) (count int, err error)

在Debug函数中添加如下代码段:

func PtracePeekData(pid int, addr uintptr, out []byte) (count int, err error)

得到结果:

└─$ go test -v=== RUN   TestDebug2022/01/06 01:10:23 Value of rip: 45cb602022/01/06 01:10:23 data at 48d8e0: eb2022/01/06 01:10:23 State: stop signal: trace/breakpoint trap--- PASS: TestDebug (0.00s)PASSok      fuzz/debugger   0.003s

得到0x48d8e0处的字节值为0xeb,和IDA中显示的一样。

同理,写内存可以通过PtracePokeData(https://bbs.pediy.com/thread-271156.htm)

<aside>
注意:后续测试时,发现这个方法进行大段内存读写很费时间。因此只在设置/恢复断点时采用如上方法修改内存。而在拍摄/恢复快照时选择使用ProcessVMReadv和ProcessVMWritev

func ProcessVMReadv(pid int, localIov []Iovec, remoteIov []RemoteIovec, flags uint) (n int, err error)
func ProcessVMWritev(pid int, localIov []Iovec, remoteIov []RemoteIovec, flags uint) (n int, err error)

</aside>

4.3.5 设置和取消断点

断点的原理就是将原本的指令修改成0xCC。所以需要

1)确定设置断点的位置,

2)读取该位置的数值并保存,

3)将数值修改为0xCC。

因此只需要使用上面提到的读写内存的功能,就可以实现设置和取消断点功能。

但是这里有一个trick需要注意,假设想要在0x1000处设置断点,将指令修改为0xCC之后,程序继续执行并中断,此时的RIP值应该是0x1001,如果想让程序继续执行,我们必须先取消断点,并把RIP减1,让程序可以继续从0x1000开始执行。这个trick会在CancelBreakPoint中实现。

断点位置的确定在之后说明,先给出函数代码。设置断点:

func SetBreakPoint(pid int, addr uintptr) ([]byte, error) {    data := make([]byte, 1)    if _, err := sys.PtracePeekData(pid, addr, data); err != nil {        return nil, errors.New("SetBreakPOint: peek data: " + err.Error())    }    if _, err := sys.PtracePokeData(pid, addr, []byte{0xcc}); err != nil {        return nil, errors.New("SetBreakPOint: poke data: " + err.Error())    }    return data, nil}

取消断点:

func CancelBreakPoint(pid int, addr uintptr, data []byte) error {    if _, err := sys.PtracePokeData(pid, addr, data); err != nil {        return errors.New("CancelBreakPOint: poke data: " + err.Error())    }     sys.PtracePeekData(pid, addr, data)    log.Printf("Cancel bp at %x, data is %x\n", addr, data)     var regs sys.PtraceRegs    if err := sys.PtraceGetRegs(pid, &regs); err != nil {        return err    }     regs.Rip = uint64(addr)     if err := sys.PtraceSetRegs(pid, &regs); err != nil {        return err    }     return nil}


4.3.6 程序继续执行

通过查找ptrace文档(https://man7.org/linux/man-pages/man2/ptrace.2.html),找到了PTRACE_CONT信号,对应golang中的:

func PtraceCont(pid int, signal int) (err error)

这个函数会重启中断的程序。

之后使用Wait4函数接收信号,

func PtraceCont(pid int, signal int) (err error)

两者结合实现程序的继续执行。

至此可以得到Debug函数:

func Debug(s string, args []string) {    //runtime.LockOSThread()     // open process    cmd := exec.Command(s, args...)    cmd.Stderr = os.Stderr    cmd.SysProcAttr = &sys.SysProcAttr{Ptrace: true}    if err := cmd.Start(); err != nil {        log.Fatal(err)    }     pid := cmd.Process.Pid    // get rip    var regs sys.PtraceRegs    if err := sys.PtraceGetRegs(pid, &regs); err != nil {        log.Panic(err)    }    log.Printf("Value of rip: %x\n", regs.Rip)     // set breakpoint1 before loop    addr := uintptr(regs.Rip + bpOffset[0])    data, err := SetBreakPoint(pid, addr)    log.Printf("Set breakpoint at %x\n", addr)    if err != nil {        log.Panic(err)    }     // Continue    if err := sys.PtraceCont(pid, 0); err != nil {        log.Panic(err)    }    var ws sys.WaitStatus    if _, err := sys.Wait4(pid, &ws, sys.WALL, nil); err != nil {        log.Fatal(err)    }     log.Println("Hit bp1")     // Cancel breakpoint    if err := CancelBreakPoint(pid, addr, data); err != nil {        log.Panic(err)    }     // need to do:    // make snapshot     // Set breakpoint before end    bpAddr = uintptr(entrypoint + bpOffset[1])    _, err = SetBreakPoint(pid, bpAddr)    if err != nil {        log.Panic(err)    }     bpAddr = uintptr(entrypoint + bpOffset[2])    _, err = SetBreakPoint(pid, bpAddr)    if err != nil {        log.Panic(err)    }     // Continue    if err = sys.PtraceCont(pid, 0); err != nil {        log.Panic(err)    }    if _, err = sys.Wait4(pid, &ws, sys.WALL, nil); err != nil {        log.Fatal(err)    }     log.Println("Hit bp2")     // need to do    // restore snapshot}

输出为:

└─$ go test -v=== RUN   TestDebug2022/01/10 01:43:54 Value of rip: 45cb602022/01/10 01:43:54 Set breakpoint at 48d8e02022/01/10 01:43:54 Hit bp12022/01/10 01:43:54 Hit bp2--- PASS: TestDebug (0.00s)PASSok      fuzz/debugger   0.003s

现在只需要替换掉测试的图片数据。

4.3.7 相关位置确定

我不清楚原文是怎么确定的断点地址,从源码看断点是硬编码到代码中的,并且在启动子进程之前取消了ASLR。

我考虑先通过静态分析确定断点代码距离程序起始位置的偏移,然后在程序起始位置中断,获取RIP的地址,再加上偏移,就可以得到断点地址了。

上面已经确定了RIP的值是0x45cb60。

一开始我打算在循环开始之前设置断点,后来发现这样设置不太方便替换测试图像数据。

在IDA中找到函数check的调用位置,发现由于这个函数太短,已经被优化掉了:

注意到在最终的cmp语句中,其中的一个比较对象sil来自于main_checkVal再加上偏移值,它对应的就是程序中的checkVal slice数组。

因此bl中保存的就是图像数据,向上溯源,寄存器rdx中保存的就应该是测试图像数据的起始地址。

如果继续向上溯源,rdx ← [rsp+88h+var_30] ← rax ← ReadFile。

因此最终第一个断点选在ReadFile函数调用结束之后,即0x48D888。

接下来选择第二个断点,因为程序有两个中断点,一个是测试没通过到达的os.Exit()函数,一个是全部测试通过到达的main_vul函数,因此我选择设置两个断点,分别在这两个函数调用之前。断点位置为:0x48da0c和0x48da1b。

得到断点位置距离程序起始位置的偏移分别为0x30d28、0x30eac和0x30ebb。

在到达第一个断点后,检查一下寄存器eax指向的地址中保存的数据是不是测试图像:

if err := sys.PtraceGetRegs(pid, &regs); err != nil {        log.Panic(err)    }dataAddr := regs.Raxdata := make([]byte, 8)sys.PtracePeekData(pid, uintptr(dataAddr), data)log.Printf("%x\n", data)

得到输出:

2022/01/10 02:52:37 ffd8ffe000104a46

发现确实是测试图像的前八个字节。


然后需要确定可写内存的地址。使用文章中提到的方法,每次启动得到的内存块地址不同(不知道是不是ASLR的问题,因为我没有处理ASLR)。

我决定直接在程序中获取可读写内存块的地址:

func getMemSecs(pid int) error {    defer trace("getMemSecs")()  // 这个函数用于测试程序执行时间,调试用    var output bytes.Buffer    cmd := exec.Command("cat", "/proc/"+strconv.Itoa(pid)+"/maps", "|", "grep", "rw")    cmd.Stdout = &output    cmd.Run()     reg := regexp.MustCompile(`(\S+)-(\S+) rw`)    result := reg.FindAllStringSubmatch(output.String(), -1)    for idx, item := range result {        begin, _ := strconv.ParseInt(item[1], 16, 0)        end, _ := strconv.ParseInt(item[2], 16, 0)         len := int(end - begin)        rIov := sys.RemoteIovec{uintptr(begin), len}        remoteIOV = append(remoteIOV, rIov)         data := make([]byte, len)        backupData = append(backupData, data)  // backupData初始化,内容为0        iov := sys.Iovec{&backupData[idx][0], uint64(len)}        localIOV = append(localIOV, iov)    }     return nil}


4.3.8 建立/恢复快照

最好的主要功能就是内存和寄存器的备份和恢复,这两个函数比较简单,没什么可说的:

func Backup(pid int) error {    defer trace("Backup")()     if _, err := sys.ProcessVMReadv(pid, localIOV, remoteIOV, 0); err != nil {        return errors.New("Backup: vm read: " + err.Error())    }     if err := sys.PtraceGetRegs(pid, &backupRegs); err != nil {        return errors.New("Backup: get regs: " + err.Error())    }     return nil} func Restore(pid int) error {    //defer trace("Restore")()    if _, err := sys.ProcessVMWritev(pid, localIOV, remoteIOV, 0); err != nil {        return errors.New("Restore: vm write: " + err.Error())    }     if err := sys.PtraceSetRegs(pid, &backupRegs); err != nil {        return errors.New("Restore: set regs: " + err.Error())    }    return nil}


4.3.9 最终代码与运行结果分析

最后对代码的结构又做了一些修改,得到Debug函数:

func Debug(s string, args []string, data []byte) {    runtime.LockOSThread()    defer trace("Debug")()    var pid int    var entrypoint uint64    var bpAddr = make([]uintptr, 3)    var bpData = make([][]byte, 3)    var stdout bytes.Buffer    var err error    //var stderr bytes.Buffer     // open process    cmd := exec.Command(s, args...)    cmd.Stdout = &stdout    cmd.SysProcAttr = &sys.SysProcAttr{Ptrace: true}    if err := cmd.Start(); err != nil {        log.Fatal(err)    }    pid = cmd.Process.Pid     // get rip    var regs sys.PtraceRegs    if err := sys.PtraceGetRegs(pid, &regs); err != nil {        log.Panic(err)    }    entrypoint = regs.Rip    log.Printf("Value of rip: %x\n", regs.Rip)     // set breakpoint1 before loop    bpAddr[0] = uintptr(entrypoint + bpOffset[0])    bpData[0], err = SetBreakPoint(pid, bpAddr[0])    log.Printf("Set breakpoint at %x\n", bpAddr)    if err != nil {        log.Panic(err)    }     // Set breakpoint before end    bpAddr[1] = uintptr(entrypoint + bpOffset[1])    _, err = SetBreakPoint(pid, bpAddr[1])    if err != nil {        log.Panic(err)    }     bpAddr[2] = uintptr(entrypoint + bpOffset[2])    _, err = SetBreakPoint(pid, bpAddr[2])    if err != nil {        log.Panic(err)    }     // Continue    if err := Continue(pid); err != nil {        log.Panic(err)    }     log.Println("Hit bp1")     // Cancel breakpoint    if err := CancelBreakPoint(pid, bpAddr[0], bpData[0]); err != nil {        log.Panic(err)    }     // Backup    getMemSecs(pid)    if err := Backup(pid); err != nil {        log.Panic(err)    }    fmt.Printf("My pid is %d, child pid is %d\n", os.Getpid(), pid)     for i := 0; i < 1000; i++ {        mutateData := getData(data, method)        // Change data        dataAddr := uintptr(backupRegs.Rax)        sys.ProcessVMWritev(pid, []sys.Iovec{{&mutateData[0], uint64(len(mutateData))}},            []sys.RemoteIovec{{dataAddr, len(mutateData)}}, 0)         // Continue        if err = Continue(pid); err != nil {            log.Panic(err)        }         // Restore        Restore(pid)    }    log.Println(timeRestore)}

注意我把所有的断点设置都放在了循环外部,循环内部只完成数据替换,继续执行,以及快照恢复功能。

代码在逻辑上没有问题,但是最终执行失败了,通过检查Continue函数中WaitStatus变量ws的StopSignal()方法的返回值,我发现在循环迭代过程中,每次Continue函数的调用并没有让vulfunc继续执行到达程序结尾处的断点,而是由于urgent I/O condition导致程序中断执行。

之后我在循环中调用了两次Continue函数,强行让程序继续执行到达第二个断点,但是迭代数次之后,程序还是崩溃掉了。

┌──(kali㉿kali)-[~/go/src/fuzz/fuzzing]└─$ go run main.go Canon_40D.jpg                                                                                                                                                                           1 ⨯2022/01/13 02:56:26 Value of rip: 45cb602022/01/13 02:56:26 SetBreakPoint using 02022/01/13 02:56:26 Set breakpoint at [48d8b4 0 0]2022/01/13 02:56:26 SetBreakPoint using 02022/01/13 02:56:26 SetBreakPoint using 02022/01/13 02:56:26 Before continue: RIP is: 0x45cb60, data at here is 0xe92022/01/13 02:56:26 trace/breakpoint trap2022/01/13 02:56:26 After continue: RIP is: 0x48d8b5, data at here is 0x892022/01/13 02:56:26 Hit bp12022/01/13 02:56:26 Cancel bp at 48d8b4, data is 482022/01/13 02:56:26 getMemSecs using 62022/01/13 02:56:26 Backup using 14My pid is 1147262, child pid is 11472682022/01/13 02:56:26 Before continue: RIP is: 0x48d8b4, data at here is 0x482022/01/13 02:56:26 urgent I/O condition2022/01/13 02:56:26 After continue: RIP is: 0x48d8b4, data at here is 0x482022/01/13 02:56:26 Before continue: RIP is: 0x48d8b4, data at here is 0x48[x]Check 1 failed!2022/01/13 02:56:26 trace/breakpoint trap2022/01/13 02:56:26 After continue: RIP is: 0x48da0d, data at here is 0x01...2022/01/13 02:56:26 Before continue: RIP is: 0x48d8b4, data at here is 0x482022/01/13 02:56:26 urgent I/O condition2022/01/13 02:56:26 After continue: RIP is: 0x48d8b4, data at here is 0x482022/01/13 02:56:26 Before continue: RIP is: 0x48d8b4, data at here is 0x482022/01/13 02:56:26 signal -12022/01/13 02:56:26 After continue:2022/01/13 02:56:26 Before continue:2022/01/13 02:56:26 no such process2022/01/13 02:56:26 Debug using 131panic: no such process goroutine 1 [running, locked to thread]:log.Panic({0xc000069e10, 0xc000069e00, 0x4dff67})        /usr/local/go/src/log/log.go:354 +0x65fuzz/fuzzer.Debug({0x4db874, 0x9}, {0xc00009af20, 0x2, 0x2}, {0xc0000c8000, 0x1f16, 0x1f17})        /home/kali/go/src/fuzz/fuzzer/debugger.go:115 +0x75emain.main()        /home/kali/go/src/fuzz/fuzzing/main.go:27 +0x1c6exit status 2

进行了N次尝试,只有一次程序正常迭代测试,没有出现崩溃的情况。

鉴于出现了执行成功的情况,所以我认为代码本身没有问题,但是可能和golang的一些特性有冲突。在github上面找到一个issue(https://github.com/golang/go/issues/37942),但是不确定是不是有关。

4.4 覆盖率检查

虽然上面的快照方法没有成功,但是覆盖率检查还是可以实现的。

在命令执行后的输出检查中,检查输出信息中是否包含strconv.Itoa(succeedCount+1)+" succeed”信息,如果包含,就将用于生成变形后数据的baseData修改为当前的mutateData,然后继续进行迭代,最终程序在迭代36939次之后成功通过三次测试,到达了漏洞位置。

func runCommand(counter int, data []byte) {    defer func() {        handler := recover()        if handler != nil {            result := fmt.Sprintf("%v", handler)            if strings.Contains(result, "123") {                filename := fmt.Sprintf("crashes/crash_%d.jpg", counter)                err := os.WriteFile(filename, data, 0644)                checkError("Write crash file", err)                return            }        }    }()     ccmd := exec.Command(cmd[0], cmd[1:]...)     if output, err := ccmd.CombinedOutput(); err != nil {        if strings.Contains(string(output), strconv.Itoa(succeedCount+1)+" succeed") {            fmt.Println(string(output))            baseData = data            succeedCount++        }        panic("Run ccmd" + ": " + err.Error())    }}

至此,第四篇文章学习结束。

 

看雪ID:LarryS

https://bbs.pediy.com/user-home-600394.htm

*本文由看雪论坛 LarryS 原创,转载请注明来自看雪社区

# 往期推荐

1.Chrome v8 issue 1234770( CVE-2021-30599)漏洞分析

2.新姿势绕过应用的ROOT检测

3.关于unicorn去搞VMP的iat那点事

4.【符号执行】KLEE安装与KLEE论文阅读笔记

5.一次Web探测服务器技术学习总结

6.解锁一辆车的非“优雅”方式

球分享

球点赞

球在看

点击“阅读原文”,了解更多!


文章来源: http://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458428140&idx=1&sn=2c8313469054f1bf41d0249f2ba1b177&chksm=b18f926686f81b70a4007461f693d06f3a59b062ea7b35fb8e4c75e7808f76f3dae79d94a29f#rd
如有侵权请联系:admin#unsafe.sh