标题: Patch crash绕过兼容性BUG

创建: 2021-01-26 12:09 更新: 2021-01-28 10:47 链接: https://scz.617.cn/unix/202101261209.txt

因故要对付古董内核2.6.18-308.24.1.el5，本文具体内容已过时，但思路是通用的。

crash有点Windows上livekd的味道，我猜这东西是受Solaris的scat启发，就跟 SystemTap绝对受Solaris的DTrace启发一样。如果折腾的事涉及内核，SystemTap和 crash或许都可以试试，gdb就不用强调了。

$ yum install crash

$ crash /usr/lib/debug/lib/modules/2.6.18-308.24.1.el5/vmlinux /dev/mem ... WARNING: /usr/lib/debug/lib/modules/2.6.18-308.24.1.el5/vmlinux and /proc/version do not match!

WARNING: /proc/version indicates kernel version: 2.6.18-308.24.1.el5

crash: please use the vmlinux file for that kernel version, or try using the System.map for that kernel version as an additional argument.

这就扯淡了，一面说内核版本不匹配，一面显示出来的内核版本是匹配的。都是用官方RPM装的，没有自编译内核。在非常确认内核版本匹配的前提下，只能说crash的兼容性有BUG。

若你的目标系统crash可以用/dev/mem，就不要往下看了，本文与你无关。

$ crash /usr/lib/debug/lib/modules/2.6.18-308.24.1.el5/vmlinux /proc/kcore ... /proc/kcore: read: No such file or directory

crash: /proc/kcore: initialization failed

同样扯淡，/proc/kcore明明存在、可访问，crash说找不到，BUG真多。

$ ls -l /proc/kcore -r-------- 1 root root 4096 Jan 26 11:11 /proc/kcore $ file -b /proc/kcore ELF 64-bit LSB core file AMD x86-64, version 1 (SYSV), SVR4-style, from 'vmlinux'

最后只能这样启动crash:

$ crash /usr/lib/debug/lib/modules/2.6.18-308.24.1.el5/vmlinux /boot/System.map-2.6.18-308.24.1.el5 ... SYSTEM MAP: /boot/System.map-2.6.18-308.24.1.el5 DEBUG KERNEL: /usr/lib/debug/lib/modules/2.6.18-308.24.1.el5/vmlinux (2.6.18-308.24.1.el5) DUMPFILE: /dev/crash ...

此种方式进入crash提示符与是否Patch内核函数devmem_is_allowed()使之恒返回1无关。

crash> dis devmem_is_allowed 0xffffffff80083bb8 : cmp $0x100,%rdi 0xffffffff80083bbf : jbe 0xffffffff80083c0d 0xffffffff80083bc1 : mov 0x437938(%rip),%r8d # 0xffffffff804bb500 0xffffffff80083bc8 : xor %esi,%esi 0xffffffff80083bca : jmp 0xffffffff80083c08 0xffffffff80083bcc : movslq %esi,%rax 0xffffffff80083bcf : imul $0x14,%rax,%rcx 0xffffffff80083bd3 : cmpl $0x1,-0x7fb44aec(%rcx) 0xffffffff80083bda : jne 0xffffffff80083c06 0xffffffff80083bdc : mov -0x7fb44afc(%rcx),%rdx 0xffffffff80083be3 : lea 0xfff(%rdx),%rax 0xffffffff80083bea : shr $0xc,%rax 0xffffffff80083bee : cmp %rax,%rdi 0xffffffff80083bf1 : jb 0xffffffff80083c06 0xffffffff80083bf3 : add -0x7fb44af4(%rcx),%rdx 0xffffffff80083bfa : shr $0xc,%rdx 0xffffffff80083bfe : cmp %rdx,%rdi 0xffffffff80083c01 : jae 0xffffffff80083c06 0xffffffff80083c03 : xor %eax,%eax 0xffffffff80083c05 : retq 0xffffffff80083c06 : inc %esi 0xffffffff80083c08 : cmp %r8d,%esi 0xffffffff80083c0b : jl 0xffffffff80083bcc 0xffffffff80083c0d : mov $0x1,%eax 0xffffffff80083c12 : retq

crash> rd -8 devmem_is_allowed 91 ffffffff80083bb8: 48 81 ff 00 01 00 00 76 4c 44 8b 05 38 79 43 00 H......vLD..8yC. ffffffff80083bc8: 31 f6 eb 3c 48 63 c6 48 6b c8 14 83 b9 14 b5 4b 1..<Hc.Hk......K ffffffff80083bd8: 80 01 75 2a 48 8b 91 04 b5 4b 80 48 8d 82 ff 0f ..u*H....K.H.... ffffffff80083be8: 00 00 48 c1 e8 0c 48 39 c7 72 13 48 03 91 0c b5 ..H...H9.r.H.... ffffffff80083bf8: 4b 80 48 c1 ea 0c 48 39 d7 73 03 31 c0 c3 ff c6 K.H...H9.s.1.... ffffffff80083c08: 44 39 c6 7c bf b8 01 00 00 00 c3 D9.|.......

crash> rd -16 0xffffffff80083c03 ffffffff80083c03: c031 1.

上面这些命令都正常执行。但这种方式启动crash，只读不可写:

crash> wr -k -16 0xffffffff80083c03 0xc0ff wr: cannot write to /dev/crash!

就读操作而言，crash与/dev/mem同步，真实反应内核态内存变化。

为了可读可写，还得用/dev/mem。

考虑到crash这种工具也不是给普通人用的，还是自己解决兼容性BUG吧。或许高版本 crash已无此兼容性BUG，但基于各种原因，没有自编译安装高版本crash。

解决思路很简单，肯定有个函数在检查内核版本是否匹配，冒险让它返回真试试。可以直接IDA反汇编crash，不过这是Linux开源世界，没必要跟自己过不去，先看源码。

$ rpm -qif $(which crash) | grep src.rpm Group : Development/Debuggers Source RPM: crash-5.1.8-1.el5.centos.src.rpm

http://ftp.iij.ad.jp/pub/linux/centos-vault/5.9/os/SRPMS/crash-5.1.8-1.el5.centos.src.rpm

Source Insight中搜"do not match!"，在filesys.c中找到match_proc_version():

/ * If only a namelist argument is entered for a live system, and the * version string doesn't match /proc/version, try to avert a failure * by assigning it to a matching System.map. / static void match_proc_version(void) { char buffer[BUFSIZE], p1, p2;

if (pc->flags & KERNEL_DEBUG_QUERY)
    return;

if (!strlen(kt->proc_version))
    return;

/*
 * 目标环境中match_file_string()返回假，设法让其返回真
 */
if (match_file_string(pc->namelist, kt->proc_version, buffer)) {
            if (CRASHDEBUG(1)) {
        fprintf(fp, "/proc/version:\n%s\n", kt->proc_version);
        fprintf(fp, "%s:\n%s", pc->namelist, buffer);
    }
    return;
}

error(WARNING, "%s%sand /proc/version do not match!\n\n",
    pc->namelist,
    strlen(pc->namelist) > 39 ? "\n         " : " ");

...

修改源码并重新编译crash是一种方案，因故不选这条路。此外，若只是绕过一个检查，只改几个字节，直接Patch二进制更符合我们的人设。

用IDA反汇编crash，match_proc_version()被inline展开到主调函数fd_init()中， match_file_string()的符号则被strip掉了。通过"/proc/version do not match!" 的交叉引用定位:

/ * match_file_string()是我自己重命名回来的，缺省没有这个符号 / 00000000004926D1 E8 BA E2 FF FF call match_file_string / * 流程至此时ZF未置位，将"test eax,eax"改成"inc eax"或"nop nop"即可 / 00000000004926D6 85 C0 test eax, eax 00000000004926D8 0F 84 C6 05 00 00 jz loc_492CA4

上面注释已经说了理论上的Patch方案，先用gdb动态Patch测试一下:

$ gdb -q -nx -x /tmp/gdbinit_x64.txt /usr/bin/crash

(gdb) display/5i $pc (gdb) x/5i 0x4926D6 0x4926d6 : test eax,eax 0x4926d8 : je 0x492ca4 0x4926de : mov rax,QWORD PTR [rip+0x6b09db] # 0xb430c0 0x4926e5 : cmp QWORD PTR [rax+0xcb0],0x0 0x4926ed : je 0x492556

(gdb) tb *0x4926d6 (gdb) r /usr/lib/debug/lib/modules/2.6.18-308.24.1.el5/vmlinux /dev/mem (gdb) i r rax eflags rax 0x0 0 eflags 0x206 [ PF IF ]

热Patch:

(gdb) set $rax=1 (gdb) c

另一种热Patch:

(gdb) set (unsigned short int )0x4926d6=0x9090 (gdb) c

热Patch后对/proc/version的检查就绕过了，但这样还是用不了/dev/mem:

crash: read error: kernel virtual address: ffffffff804bd2e0 type: "possible" WARNING: cannot read cpu_possible_map crash: read error: kernel virtual address: ffffffff8045f5a0 type: "present" WARNING: cannot read cpu_present_map crash: read error: kernel virtual address: ffffffff8045a260 type: "online" WARNING: cannot read cpu_online_map crash: read error: kernel virtual address: ffffffff80461210 type: "xtime"

crash: this kernel may be configured with CONFIG_STRICT_DEVMEM, which renders /dev/mem unusable as a live memory source.

crash: trying /proc/kcore as an alternative to /dev/mem

/proc/kcore: read: Operation not permitted crash: /proc/kcore: initialization failed

Program exited with code 01.

目标系统crash用不了/dev/mem，除了crash本身的兼容性BUG，还有一个来自内核态的安全限制。crash会检查编译内核时是否指定过CONFIG_STRICT_DEVMEM，是否能不受限地读取/dev/mem，这个安全限制是内核态的，不是crash应用程序本身的。缺省情况下用户态进程读取/dev/mem受限，只能读写前1MB多的数据，于是crash转而使用 /proc/kcore，也失败了。crash使用/proc/kcore失败应该是另一个兼容性BUG，我懒得理它，盯着/dev/mem用吧。

不考虑自编译内核时禁用CONFIG_STRICT_DEVMEM，至少有两种方式热消除这个安全限制。用SystemTap让内核函数devmem_is_allowed()恒返回1:

$ stap -g -e 'probe kernel.function("devmem_is_allowed").return {$return=1}'

或者自己写LLKM去Patch devmem_is_allowed():

$ insmod /tmp/kernelwrite.ko address=0xffffffff80083c03 value=ffc0 insmod: error inserting '/tmp/kernelwrite.ko': -1 Operation not permitted

$ dmesg | tail -2 ffffffff80083c03: 31 c0 1. ffffffff80083c03: ff c0 ..

$ xxd -g 1 -s $[0xffffffff80083c03-0xffffffff7fe00000] -l 2 /dev/mem 0283c03: ff c0 ..

切勿照搬上面的命令，领会精神后自行反汇编并Patch相应地址。

假设已经消除CONFIG_STRICT_DEVMEM限制，如下gdb操作对crash进行动态Patch:

$ gdb -q -nx -x /tmp/gdbinit_x64.txt /usr/bin/crash

tb 0x4926d6 commands $bpnum silent i r rax eflags set (unsigned short int *)$rip=0x9090 c end r /usr/lib/debug/lib/modules/2.6.18-308.24.1.el5/vmlinux /dev/mem

进入crash提示符，可读可写。

静态Patch如下:

$ fc /b crash.orig crash 000926D6: 85 90 000926D7: C0 90

后续使用的常规组合是:

$ stap -g -e 'probe kernel.function("devmem_is_allowed").return {$return=1}'

或

$ insmod /tmp/kernelwrite.ko address=0xffffffff80083c03 value=ffc0

$ crash /usr/lib/debug/lib/modules/2.6.18-308.24.1.el5/vmlinux /dev/mem