Exercise 1#

程序源码如下：

1
#include <iostream>
2
#include <stdio.h>
3
#include <stdlib.h>
4
#include <string.h>
5

6
using namespace std;
7

8
int main() {
9

10
  string str;
11

12
  cout << "enter input string: ";
13
  getline(cin, str);
14
  cout << str << endl << str[0] << endl;
15

16
  if (str[0] == 0 || str[str.length() - 1] == 0) {
17
    abort();
18
  } else {
19
    int count = 0;
20
    char prev_num = 'x';
21
    while (count != str.length() - 1) {
22
      char c = str[count];
23
      if (c >= 48 && c <= 57) {
24
        if (c == prev_num + 1) {
25
          abort();
26
        }
27
        prev_num = c;
28
      }
29
      count++;
30
    }
31
  }
32

33
  return 0;
34
}

使用 CC=afl-clang-lto CXX=afl-clang-lto++ cmake -S . -B build 生成编译配置，然后通过 cmake --build build 编译项目。

简单分析一下几个可以造成 crash 的地方，然后跑一下 fuzz 看看能不能对上：

1. str[0] == \x00
2. str[str.length() -1] == \x00
3. 下一个读取到的数字比上一个读取到的数字大一
4. \n，EOF

根据 Exercise 1 的要求，我们使用如下脚本生成 5 个 seeds：

1
#!/usr/bin/env bash
2

3
mkdir seeds
4
for i in {0..4}; do
5
  dd if=/dev/urandom of=seeds/seed_"$i" bs=64 count=10
6
done

然后跑 afl-fuzz -i seeds -o out/ -m 0 -- ./build/simple_crash，刚跑一秒就把三个 crash 都找到了：

可以看到第一个对上了 Case 2，第二个对上了 Case 1，第三个对上了 Case 3。

IMPORTANT

第四个 Case 找不到，那时因为当触发的 crash 是由 Undefined Behaviour 导致时，AFL++ 会认为它比较 flaky，自动把它剔除掉。因为 UB 一类的，可能在不同编译 / 优化 / 运行中表现各不相同，从而不能产生一种稳定可复现的 crash 。

既然如此，我们只要增强它的 crash 表现，使其更加可确定即可，比如：

if (str.length() == 0)
  abort();

亦或者，我们打开 Sanitizer，这样就可以将语言层面的未定义行为变成 fuzzer 能稳定识别的崩溃信号了。

#!/usr/bin/env bash

cmake -S . -B build \
  -DCMAKE_C_COMPILER=afl-clang-lto \
  -DCMAKE_CXX_COMPILER=afl-clang-lto++ \
  -DCMAKE_C_FLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address,undefined" \
  -DCMAKE_CXX_FLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address,undefined"

通过上面的指令生成编译配置，开启 AddressSanitizer (ASan) 和 UndefinedBehaviorSanitizer (UBSan)，然后跑 fuzz 前设置一下这两个环境变量：

export ASAN_OPTIONS=abort_on_error=1:symbolize=0:detect_leaks=0
export UBSAN_OPTIONS=abort_on_error=1

debug 时使用：

export ASAN_OPTIONS=abort_on_error=1:symbolize=1:detect_leaks=0
export UBSAN_OPTIONS=abort_on_error=1:print_stacktrace=1

Exercise 2#

没啥崩溃点，只有这一个 abort, 输入 ffl 即可触发。

1
} else if (input[i] == 'l') {
2
    if (crew.num == 0) {
3
        abort();
4
    }
5
    land();
6
}

我使用的 input 是随机生成的 200 字节长 De Bruijn Sequence，实际上沿用 Exercise 1 的 seeds 应该也可以。

观察跑出来的几个 crashes, 发现全都符合 ffl 的行为，多的 f 被 h 抵消。

Exercise 3#

代码太多就不放了，简单罗列一下 abort points:

• choose_color: 输入纯数字
• min_alt: 输入小于 0
• min_airspeed: 输入小于 0
• fuel_cap: 输入小于 0
• check_alt: 传入 alt 小于 0
• check_fuel: 传入 fuel 小于 0
• check_speed: 传入 speed 小于 0

这里的话，我遵循提示，在 cmake 创建配置文件的时候多加了一个 -DCMAKE_EXPORT_COMPILE_COMMANDS=1 参数，用于生成编译命令到 compile_commands.json，并尝试使用 Sourcetrail 来阅读源码。但是发现用这个工具还不如我直接在 nvim 里面看代码来得快……或许以后分析很大的项目时可以再试试。

这节练习给了这么一个 template：

1
/*
2
 * This file isolates the Specs class and tests out the
3
 * choose_color function specifically.
4
 */
5

6
#include "specs.h"
7

8
int main(int argc, char **argv) {
9
  // In order to call any functions in the Specs class, a Specs
10
  // object is necessary. This is using one of the constructors
11
  // found in the Specs class.
12
  Specs spec(505, 110, 50);
13
// By looking at all the code in our project, this is all the
14
// necessary setup required. Most projects will have much more
15
// that is needed to be done in order to properly setup objects.
16

17
// This section should be in your code that you write after all the
18
// necessary setup is done. It allows AFL++ to start from here in
19
// your main() to save time and just throw new input at the target.
20
#ifdef __AFL_HAVE_MANUAL_CONTROL
21
  __AFL_INIT();
22
#endif
23

24
  spec.choose_color();
25
  // spec.min_alt();
26

27
  return 0;
28
}

我们可以通过定义 __AFL_HAVE_MANUAL_CONTROL 来设置 fuzz 入口。

先测试 choose_color，如果输入纯数字就会崩：

但这里多了一个 \x20，即空格导致的崩溃，是我没想到的，研究研究。

1
std::cin >> color;
2
if (isNumber(color))
3
  abort();
4

5
bool Specs::isNumber(std::string str) {
6
  for (int i = 0; i < str.length(); i++) {
7
    if (isdigit(str[i]) == 0)
8
      return false;
9
  }
10
  return true;
11
}

choose_color 是用 cin >> 读取的输入，由于 >> 的逻辑是先跳过所有 spaces，然后从第一个非空字符读取到下一个 space 停止，所以输入 \x20 的话，什么都不会读到，导致 color = ""，for 循环根本不会进入，返回 true 导致崩溃。

其它的没啥好说的，但是在 slice fuzz min_airspeed 的时候发现 exec speed: 55.54/sec，简直是在拿显微镜扫地 o_O

究其原因的话，可能是因为 fuzzer 计算 exec 是按处理完一整轮来算的，可是现在这个情况内部有一个循环，可能触发多次输入，所以如果输入样本很大的话，就会处理很久。

1
void Specs::min_airspeed() {
2
  bool out_of_bounds = true;
3
  std::cout << "enter aircraft minimum airspeed: ";
4
  std::cin >> speed;
5
  do {
6
    out_of_bounds = false;
7
    if (speed < 0)
8
      abort();
9
    if (speed < 100) {
10
      std::cout << "too low. please re-enter: ";
11
      std::cin >> speed;
12
      out_of_bounds = true;
13
    } else if (speed > 200) {
14
      std::cout << "too high. please re-enter: ";
15
      std::cin >> speed;
16
      out_of_bounds = true;
17
    }
18
  } while (out_of_bounds);
19
}

这里发现第二个 crash 有点奇怪：

这是因为 >> 在读取数字的时候也有特殊的规则，它会自动拆分数字。即 1-3113\x09 被拆分为 1 和 -3113 两部分，被拆开的那部分会留在输入缓冲区等待下一次读取的时候发出去，所以这里触发的逻辑是先判断 speed < 100 重新读取，然后发送负数触发 abort 。

最后还剩下三个 check 函数我没测，因为它们相对前面几个来说更吃运气一点，感觉有点浪费时间，就且先跳过了。