【持续更新】C/C++ 踩坑记录（一）
Web前端之巅 2023-09-03 22:30:43 2023-09-03 0 0
未定义行为之 NULL dereference
下面这段代码中 is_valid() 解引用了空指针 str，我们的直觉是编译运行后将迎来 SIGSEGV，然而事情并非所期望的那样。
/* * ub_null.c - 未定义行为演示 之 NULL dereference */#include <stdio.h>#include <string.h>int is_valid(const char *str){ if(*str == 0x80) return 1; if(str == NULL) return 0; return strcmp(str, "expected string") == 0;}int main(void){ const char *str = NULL; printf("%d\n", is_valid(str)); return 0;}lyazj@HelloWorld:~$ gcc --versiongcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0Copyright (C) 2021 Free Software Foundation, Inc.This is free software; see the source for copying conditions. There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.lyazj@HelloWorld:~$ gcc -Wall -Wshadow -Wextra ub_null.c -o ub_null -O0ub_null.c: In function ‘is_valid’:ub_null.c:6:11: warning: comparison is always false due to limited range of data type [-Wtype-limits] 6 | if(*str == 0x80) return 0; | ^~lyazj@HelloWorld:~$ ./ub_null0结合 GCC 发出的警告，不难推断出条件表达式 *str == 0x80 在编译期被求值且相应的 if 语句被优化掉了，而且这是在 O0 的优化等级下。以下的反汇编结果验证了这一点。
lyazj@HelloWorld:~$ objdump --disassemble=is_valid -j.text ub_nullub_null: file format elf64-x86-64Disassembly of section .text:0000000000001169 <is_valid>: 1169: f3 0f 1e fa endbr64 116d: 55 push %rbp 116e: 48 89 e5 mov %rsp,%rbp 1171: 48 83 ec 10 sub $0x10,%rsp 1175: 48 89 7d f8 mov %rdi,-0x8(%rbp) 1179: 48 83 7d f8 00 cmpq $0x0,-0x8(%rbp) 117e: 75 07 jne 1187 <is_valid+0x1e> 1180: b8 00 00 00 00 mov $0x0,%eax 1185: eb 1e jmp 11a5 <is_valid+0x3c> 1187: 48 8b 45 f8 mov -0x8(%rbp),%rax 118b: 48 8d 15 72 0e 00 00 lea 0xe72(%rip),%rdx # 2004 <_IO_stdin_used+0x4> 1192: 48 89 d6 mov %rdx,%rsi 1195: 48 89 c7 mov %rax,%rdi 1198: e8 d3 fe ff ff call 1070 <strcmp@plt> 119d: 85 c0 test %eax,%eax 119f: 0f 94 c0 sete %al 11a2: 0f b6 c0 movzbl %al,%eax 11a5: c9 leave 11a6: c3 ret我们在同一环境对 O3 优化等级做相同的实验，得到了相同的结果：
lyazj@HelloWorld:~$ gcc -Wall -Wshadow -Wextra ub_null.c -o ub_null -O3ub_null.c: In function ‘is_valid’:ub_null.c:6:11: warning: comparison is always false due to limited range of data type [-Wtype-limits] 6 | if(*str == 0x80) return 0; | ^~lyazj@HelloWorld:~$ ./ub_null0lyazj@HelloWorld:~$ objdump --disassemble=is_valid -j.text ub_nullub_null: file format elf64-x86-64Disassembly of section .text:00000000000011a0 <is_valid>: 11a0: f3 0f 1e fa endbr64 11a4: 48 85 ff test %rdi,%rdi 11a7: 74 27 je 11d0 <is_valid+0x30> 11a9: 48 83 ec 08 sub $0x8,%rsp 11ad: 48 8d 35 50 0e 00 00 lea 0xe50(%rip),%rsi # 2004 <_IO_stdin_used+0x4> 11b4: e8 a7 fe ff ff call 1060 <strcmp@plt> 11b9: 85 c0 test %eax,%eax 11bb: 0f 94 c0 sete %al 11be: 48 83 c4 08 add $0x8,%rsp 11c2: 0f b6 c0 movzbl %al,%eax 11c5: c3 ret 11c6: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) 11cd: 00 00 00 11d0: 31 c0 xor %eax,%eax 11d2: c3 ret接下来我们用下面的两行代码替换被优化掉的 if 语句，看看会发生什么：
char head = *str;if(head == 0x80) return 0;lyazj@HelloWorld:~$ gcc -Wall -Wshadow -Wextra ub_null.c -o ub_null -O0ub_null.c: In function ‘is_valid’:ub_null.c:10:11: warning: comparison is always false due to limited range of data type [-Wtype-limits] 10 | if(head == 0x80) return 0; | ^~lyazj@HelloWorld:~$ ./ub_null Segmentation faultlyazj@HelloWorld:~$ objdump --disassemble=is_valid -j.text ub_nullub_null: file format elf64-x86-64Disassembly of section .text:0000000000001169 <is_valid>: 1169: f3 0f 1e fa endbr64 116d: 55 push %rbp 116e: 48 89 e5 mov %rsp,%rbp 1171: 48 83 ec 20 sub $0x20,%rsp 1175: 48 89 7d e8 mov %rdi,-0x18(%rbp) 1179: 48 8b 45 e8 mov -0x18(%rbp),%rax 117d: 0f b6 00 movzbl (%rax),%eax 1180: 88 45 ff mov %al,-0x1(%rbp) 1183: 48 83 7d e8 00 cmpq $0x0,-0x18(%rbp) 1188: 75 07 jne 1191 <is_valid+0x28> 118a: b8 00 00 00 00 mov $0x0,%eax 118f: eb 1e jmp 11af <is_valid+0x46> 1191: 48 8b 45 e8 mov -0x18(%rbp),%rax 1195: 48 8d 15 68 0e 00 00 lea 0xe68(%rip),%rdx # 2004 <_IO_stdin_used+0x4> 119c: 48 89 d6 mov %rdx,%rsi 119f: 48 89 c7 mov %rax,%rdi 11a2: e8 c9 fe ff ff call 1070 <strcmp@plt> 11a7: 85 c0 test %eax,%eax 11a9: 0f 94 c0 sete %al 11ac: 0f b6 c0 movzbl %al,%eax 11af: c9 leave 11b0: c3 ret段错误如愿以偿地发生了，且是来自读取 str 处 1 字节并进行零扩展的 movzbl 指令，之前看到的编译期求值没有再次发生。
现在升高优化等级至 Og，编译期求值并优化掉第一个 if 语句的特效回归了：
lyazj@HelloWorld:~$ gcc -Wall -Wshadow -Wextra ub_null.c -o ub_null -Ogub_null.c: In function ‘is_valid’:ub_null.c:7:11: warning: comparison is always false due to limited range of data type [-Wtype-limits] 7 | if(head == 0x80) return 0; | ^~lyazj@HelloWorld:~$ ./ub_null0lyazj@HelloWorld:~$ objdump --disassemble=is_valid -j.text ub_nullub_null: file format elf64-x86-64Disassembly of section .text:0000000000001169 <is_valid>: 1169: f3 0f 1e fa endbr64 116d: 48 85 ff test %rdi,%rdi 1170: 74 1d je 118f <is_valid+0x26> 1172: 48 83 ec 08 sub $0x8,%rsp 1176: 48 8d 35 87 0e 00 00 lea 0xe87(%rip),%rsi # 2004 <_IO_stdin_used+0x4> 117d: e8 de fe ff ff call 1060 <strcmp@plt> 1182: 85 c0 test %eax,%eax 1184: 0f 94 c0 sete %al 1187: 0f b6 c0 movzbl %al,%eax 118a: 48 83 c4 08 add $0x8,%rsp 118e: c3 ret 118f: b8 00 00 00 00 mov $0x0,%eax 1194: c3 retGCC 如何优化，除取决于编译选项外，同样取决于程序员编写什么样的源代码，这一点不足为奇。然而，当优化等级升至 O2 时，更为不好的事情发生了：
lyazj@HelloWorld:~$ gcc -Wall -Wshadow -Wextra ub_null.c -o ub_null -O2ub_null.c: In function ‘is_valid’:ub_null.c:7:11: warning: comparison is always false due to limited range of data type [-Wtype-limits] 7 | if(head == 0x80) return 0; | ^~In function ‘is_valid’, inlined from ‘main’ at ub_null.c:15:3:ub_null.c:9:10: warning: argument 1 null where non-null expected [-Wnonnull] 9 | return strcmp(str, "expected string") == 0; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~In file included from ub_null.c:2:ub_null.c: In function ‘main’:/usr/include/string.h:156:12: note: in a call to function ‘strcmp’ declared ‘nonnull’ 156 | extern int strcmp (const char *__s1, const char *__s2) | ^~~~~~lyazj@HelloWorld:~$ ./ub_nullSegmentation faultlyazj@HelloWorld:~$ objdump --disassemble=is_valid -j.text ub_nullub_null: file format elf64-x86-64Disassembly of section .text:00000000000011b0 <is_valid>: 11b0: f3 0f 1e fa endbr64 11b4: 48 83 ec 08 sub $0x8,%rsp 11b8: 48 8d 35 45 0e 00 00 lea 0xe45(%rip),%rsi # 2004 <_IO_stdin_used+0x4> 11bf: e8 9c fe ff ff call 1060 <strcmp@plt> 11c4: 85 c0 test %eax,%eax 11c6: 0f 94 c0 sete %al 11c9: 48 83 c4 08 add $0x8,%rsp 11cd: 0f b6 c0 movzbl %al,%eax 11d0: c3 ret值得注意的是，现在段错误来自 strcmp() 中的 NULL dereference，且 is_valid() 的反汇编出奇地简单，GCC 同时干掉了两个 if 语句！因为我们首先访问了 str 处的 1 字节，由于 NULL dereference 是典型的 UB，编译器便假定了 str != NULL，这样第二个 if 语句也可以被优化掉！现在，我们产生了具有严重漏洞的 is_valid() 函数，当 str == NULL 时，程序将发生严重错误。
解决 bug 的方法是显然的，即将 head 转换为 unsigned char 再比较，并调换两个 if 语句的顺序。NULL dereference，这是一个曾经让 Linux 内核爆出严重漏洞的 UB，我们刚刚成功复现了这一过程。诚然，此处的程序是异常简单的，看出两个写反的 if 语句非常容易；但对于代码业务特别复杂的场景，特别是对一行代码需要数行注释的底层代码或其它核心代码而言，这个 bug 可能一致遗留下来，并成为一个长期休眠的不定时炸弹。它的出现让许多可能是至关重要的代码段，如第二个 if 语句失效，可能给程序使用者造成难以预计的后果。还好当前版本的 GCC 友好地给出了应有的警告，这也再次向我们证明，随意地忽略编译器给出的 Warning 是不可取的。
Google 等团队开发的 sanitizer 已经集成到了当前版本的 GCC 中，让我们用 sanitizer 更为有效地发现上述未定义行为：
lyazj@HelloWorld:~$ gcc -Wall -Wshadow -Wextra ub_null.c -o ub_null -O2 -fsanitize=undefined -fno-sanitize-recover=allub_null.c: In function ‘is_valid’:ub_null.c:7:11: warning: comparison is always false due to limited range of data type [-Wtype-limits] 7 | if(head == 0x80) return 0; | ^~lyazj@HelloWorld:~$ ./ub_nullub_null.c:6:8: runtime error: load of null pointer of type 'const char'看到这里，是不是很轻松就发现了两个 if 语句写反的问题？