CTF

题目下载地址：babyqemu.tar.gz 分析 tar xvzf babyqemu.tar.gz解压看到启动脚本launch.sh 1 2 3 4 5 6 7 8 9 10 #! /bin/sh ./qemu-system-x86_64 \ -initrd ./rootfs.cpio \ -kernel ./vmlinuz-4.8.0-52-generic \ -append 'console=ttyS0 root=/dev/ram oops=panic panic=1' \ -enable-kvm \ # 需要CPU virtualization，现在与hyper-v共存的VMware不支持此选项。可以删掉 -monitor /dev/null \ -m 64M --nographic -L ./dependency/usr/local/share/qemu \ -L pc-bios \ -device hitb,id=vda 在最后一行可以看到设备名称为hitb，在ida左侧Functions window，ctrl+f搜索hitb就可以找到相关函数。通过在ida的Local Types窗口搜索hitb可以找到HitbState结构体，其中还包含dma_state结构体。 ...

最近想学一下qemu escape的基础知识，进而分析一些Qemu的CVE漏洞。 本文主要参考raycp师傅的两篇文章。[1] [2] Qemu概述 每个运行的qemu虚拟机对应于host上的一个进程，虚拟机的执行线程（如CPU线程、I/O线程等）对应于qemu进程中的一个线程。 qemu的内存结构，根据QEMU Case Study，虚拟机对应的内存结构为如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Guest' processes +--------------------+ Virtual addr space | | +--------------------+ | | \__ Page Table \__ \ \ | | Guest kernel +----+--------------------+----------------+ Guest's phy. memory | | | | +----+--------------------+----------------+ | | \__ \__ \ \ | QEMU process | +----+------------------------------------------+ Virtual addr space | | | +----+------------------------------------------+ | | \__ Page Table \__ \ \ | | +----+-----------------------------------------------++ Physical memory | | || +----+-----------------------------------------------++ ...

MISC 内核文件区别 vmlinux 是静态链接的可执行文件，未压缩的内核，最原始的文件，可以用来调试。 vmlinuz 是可引导的、压缩的内核。没有调试信息等数据，不可用于调试。启动时会自解压，通常会显示以下信息 1 2 Decompressing Linux... done Booting the kernel. zImage 是经过压缩的小内核（小于512KB）。 bzImage 是经过压缩的大内核（大于512KB）。 Initial Ramdisk 名字类似initramfs.cpio 文件，一般可以使用cpio读取其中的文件。 1 2 $ find . | cpio -o --format=newc > initramfs.cpio # compress $ sudo cpio -idmv < initramfs.cpio # depress 有时也经过了gzip的压缩。 1 2 3 $ mv initramfs.cpio initramfs.cpio.gz $ gunzip initramfs.cpio.gz # 解压得到initramfs.cpio $ cpio -idmv < initramfs.cpio 更改为正确的后缀之后，图形界面“归档管理器”也可以打开。 ...

环境配置 1 $ sudo apt install qemu-user gdb-multiarch 安装完成后就可以运行平台上的静态链接文件了，会自动调用qemu执行。 动态链接程序 对于动态链接的程序，还需要安装跨平台的lib。 1 $ apt-cache search "libc" | grep arm 安装类似libc6-ARCH-cross。 动态链接库被安装在类似/usr/arm-linux-gnueabihf/的路径。qemu不知道动态链接的位置，它预期在类似/etc/qemu-binfmt/arm的路径，所以可以设置软链接来避免用-L来指定链接库位置。 1 2 3 $ sudo mkdir /etc/qemu-binfmt $ sudo ln -s /usr/arm-linux-gnueabihf /etc/qemu-binfmt/arm $ sudo ln -s /usr/aarch64-linux-gnu/ /etc/qemu-binfmt/aarch64 # 对于aarch64 ...

题目分析 防护比re-alloc多了FULL RELRO和PIE。其他没有改变。 总体思路 程序没有show函数，所以通过修改stdout的方式泄露libc。 将一个chunk同时释放到tcache和unsorted bin，partial overwrite fd部分，指向stdout，需要爆破4bit。取得stdout后修改进行泄露。 最后修改__realloc_hook为one_gadget得到shell。 主要难点在布局构造。 ...

tcache_tear 分析 1 2 3 4 5 6 7 8 Arch: amd64-64-little RELRO: Full RELRO Stack: Canary found NX: NX enabled PIE: No PIE (0x400000) FORTIFY: Enabled libc_version: Ubuntu GLIBC 2.27-3ubuntu1 程序开始在bss段上读入了一个0x20的名字 malloc: 输入指定size，分配，指针ptr同样存储在bss，读入size-16的字符，这里字符个数可以溢出 free: 释放ptr空间，指针悬空，可以double free，程序使用了tcache，且在这个版本释放没有任何的检查 info: 打印姓名 总体思路 利用tcache double free，可以对任意地址进行改写。在name处伪造一个chunk释放到unsorted bin，进行libc base的泄露。将__free_hook改写为system地址。 伪造chunk注意绕过free的所有检查。伪造完成的结构如下： 1 2 3 4 5 6 7 8 9 10 +----------+ | | | | | 0x421 | | | +----------+ | 0x21 | +----------+ | 0x21 | +----------+ tcache默认最多有64个，第1个是0x20大小，递推第64个也就是0x410。所以将name处伪造为0x420大小。第一个chunk的chunk->size=0x420|pre_in_use，避免backward consolidate，第三个chunk的chunk->size=0x20|pre_in_use，避免forward consolidate。 ...

前言 CTF题目中经常会给出libc的文件，首先需要做的就是确定libc的版本，对程序进行针对性的攻击。最直接的确定方法就是直接运行该libc./libc.so.6，但通常由于本机ld版本与libc版本不匹配，发生段错误。 确定完大版本号还不够，因为就算是同一版本的libc也会有较大的变动。比方说，与最开始的2.29版本相比，gnu libc库的release/2.29/master分支的tcache_perthread_struct->counts的变量类型都变了；__libc_malloc中取用tcache的判定，也由判断指针是否为空变成了判断counts是否大于0。这些细节很大程度上影响了exploit的书写。 下面以pwnable.tw re-alloc的libc为例，写一写我的经验。 ...

题目分析 1 2 3 4 5 6 Arch: amd64-64-little RELRO: Partial RELRO Stack: Canary found NX: NX enabled PIE: No PIE (0x400000) FORTIFY: Enabled 是一个典型的菜单类程序 1 2 3 4 5 6 7 8 $$$$$$$$$$$$$$$$$$$$$$$$$$$$ 🍊 RE Allocator 🍊 $$$$$$$$$$$$$$$$$$$$$$$$$$$$ $ 1. Alloc $ $ 2. Realloc $ $ 3. Free $ $ 4. Exit $ $$$$$$$$$$$$$$$$$$$$$$$$$$$ Alloc: index只能取0或1；size必须<=0x78；然后使用realloc(0, size)分配，通过源码可以看出，这就相当于malloc(size)。这里存在null byte overflow（然而没什么用似乎，一开始我一直卡在这里想如何利用，完全没注意到后一个漏洞。。。 1 2 3 /* realloc of null is supposed to be same as malloc */ if (oldmem == 0) return __libc_malloc (bytes); Realloc: size同样<=0x78。realloc有几种情况：请求大小自己可以满足；尝试向后扩展(top chunk或!inuse (next))；__int_malloc请求新块。（这里存在UAF，输入size为0 Free：realloc(ptr, 0)相当于free(ptr)，同时将指针数组置空。 1 2 3 4 if (bytes == 0 && oldmem != NULL) { __libc_free (oldmem); return 0; } libc_version: glibc 2.29 with tcache。该版本libc的源码。下一篇文章说一下如何确定的libc版本，如何确定的有tcache，以及如何使用指定libc运行程序。 此外，这个版本中出现了对tcache double free的一个检查机制。 ...

目前 Linux 标准发行版中使用的堆分配器是 glibc 中的堆分配器：ptmalloc2。ptmalloc2 主要是通过 malloc/free 函数来分配和释放内存块。 需要注意的是，在内存分配与使用的过程中，Linux 有这样的一个基本内存管理思想，只有当真正访问一个地址的时候，系统才会建立虚拟页面与物理页面的映射关系。 基本操作 malloc malloc(size_t n) 当 n=0 时，返回当前系统允许的堆的最小内存块。 当 n 为负数时，由于在大多数系统上，size_t 是无符号数（这一点非常重要），所以程序就会申请很大的内存空间，但通常来说都会失败，因为系统没有那么多的内存可以分配。 free free(void *p) 当 p 为空指针时，函数不执行任何操作。 当 p 已经被释放之后，再次释放会出现乱七八糟的效果，这其实就是 double free。 除了被禁用 (mallopt) 的情况下，当释放很大的内存空间时，程序会将这些内存空间还给系统，以便于减小程序所使用的内存空间。 背后的系统调用 这些函数背后的系统调用主要是 (s)brk 函数以及 mmap, munmap 函数。 ...

first-fit 如果一个chunk可用且足够大，那么就会使用这个chunk。 calc_tcache_idx tcache(thread local caching) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 /* We want 64 entries. This is an arbitrary limit, which tunables can reduce. */ # define TCACHE_MAX_BINS 64 # define MAX_TCACHE_SIZE tidx2usize (TCACHE_MAX_BINS-1) /* Only used to pre-fill the tunables. */ # define tidx2usize(idx) (((size_t) idx) * MALLOC_ALIGNMENT + MINSIZE - SIZE_SZ) /* When "x" is from chunksize(). */ # define csize2tidx(x) (((x) - MINSIZE + MALLOC_ALIGNMENT - 1) / MALLOC_ALIGNMENT) /* When "x" is a user-provided size. */ # define usize2tidx(x) csize2tidx (request2size (x)) /* With rounding and alignment, the bins are... idx 0 bytes 0..24 (64-bit) or 0..12 (32-bit) idx 1 bytes 25..40 or 13..20 idx 2 bytes 41..56 or 21..28 etc. */ tcache拥有和fastbin差不多的结构。默认情况下，64个bin，每个bin最多7个chunk 64bit: IDX = (CHUNKSIZE - 0x11) / 0x10 ...