错误：无法使用afl-g++编译

[Archie-King]

您好！
我在ImageMagick中设置编译器为afl的时候，可以成功设置CC=afl-gcc（afl-clang），但在设置CXX=afl-g++（afl-clang++）时报错无法成功。
出错如下图：

根据其他Issues，这应该是导致afl-fuzz过程中无法成功fuzzing。

[-] PROGRAM ABORT : Program './magick' is a shell script
         Location : check_binary(), afl-fuzz.c:6957

初步Google后，部分论坛指出可能和cpp，g++环境有关，但install时无法成功安装。

而在相关日志config.log中，该报错处的日志详情为乱码，无法显示字符，无从得知details。

afl-gcc成功如下图：

请问问题原因何在，如何能解决这个问题？期望作者大佬的解答！

相关环境如下：
Ubuntu：Linux ubuntu 5.13.0-40-generic（更新至当前最新状态）
ImageMagick：7.1.0-20
AFL：2.57b

[lcatro]

这里有几个问题,我帮你理一下:

1.使用g++编译失败
这在config.log中就给出提示了,是因为直接执行g++命令失败,所以你应该直接用控制台试一试g++ -v看看能不能执行成功,如果提示缺少g++的话就apt install g++.gcc和g++不是同一个编译器
如果是apt install g++出了错误,那就附上相关错误进一步排查

2.'./magick' is a shell script
这是常见错误了,因为afl-fuzz是不能执行脚本文件的,只能执行二进制文件,所以要去找到那个二进制文件去跑fuzz

[Archie-King]

非常感谢您的解答！上面的问题已经解决。
这里确实应该和Ubuntu的版本有关，我使用的Ubuntu版本中的g++相关依赖不适配，我在更换为Ubuntu20后，现在已经能开始Fuzzing。
但我在后续Fuzz ing过程中遇到了些新的问题，并未找到解决方法，相关问题如下：

1. 测试输入用例的png（fuzzdate/samples/png/common和afl/testcases/png均尝试）就直接放在utilities/input目录下，测试正常进行。但测试开始不久后Process timing中会显示：last new path : none yet (odd, check syntax!)。Google后可能是与没有检测到输入或路径有关，但没有找到解决方法。
   

担心后续已被修复，ImageMagick已更换为最早的版本进行测试。
请问您知道这里如何解决吗？
第一次接触学习Fuzzing，可能问题比较小白，希望您多担待。再次感谢您的解答帮助！

[lcatro]

Hi @Archie-King
Google找到的结果确实就是真实的答案了,但是这个问题要怎么排查是不是因为没有正确插桩导致的呢,你可以这样试试:

nm ./elf  | grep afl   #  如果使用AFL编译的话
nm ./elf  | grep sanitize   #  如果使用libFuzzer
nm ./elf  | grep asan  #  如果要查看是否有引入成功ASAN

nm命令是为了从可执行程序中获取所有符号信息,当AFL成功引入插桩的话,那就会把一些AFL内置的功能也会一并编译进去目标程序,此时nm命令就可以找到AFL的内置函数.

如果nm命令没有AFL内置函数,那就是因为编译的时候没有指定好afl-gcc/afl-g++
如果nm命令有AFL内置函数,那就要看看是不是fuzz wrapper构造有问题了:1.输入的数据有流入到指定函数嘛? 2.程序是不是缺少某个校验必定崩溃

[Archie-King]

您好@lcatro
非常非常感谢您之前的细致耐心解答，我排查到了问题所在，确实是没能完全插桩编译(make && make install)导致，现在已成功run了。
但是我后续还有些疑问，不得不再次来麻烦您。

1. 用图片做测试用例会非常占用磁盘空间吗？我也询问了做模糊测试相关的博士学长，他们虽然没有用过图片用例，但似乎也没有我这么离谱？
2. 我用了3个小时时间跑出了一个crashes，然后200G硬盘空间全部被占用导致测试中断（新建干干净净的虚拟机）。

被占用空间为根目录下的/tmp。在测试开始后，文件夹中生成了大量magick-（+一串随机数字）……开头的文件，猜测可能是临时生成的变异文件？小则六七八兆，大则十几G。可能这个原因导致崩溃crash出现？

初始输入测试用例仅采用了fuzzdate数据集中最小的一个png（98字节）。这样的结果我也觉得很离谱？！？


仅显示的唯一unique：

再次诚挚的感谢您在我学习AFL过程中对我的帮助！

[lcatro]

Hi @Archie-King
看你的回复判断应该是属于科研向的同学了,给你简单说明一下坑点

1. 用图片做测试用例会非常占用磁盘空间吗？我也询问了做模糊测试相关的博士学长，他们虽然没有用过图片用例，但似乎也没有我这么离谱？

图片做测试用例不会非常占用磁盘空间,占用磁盘空间是因为ImageMagic的内部实现,下面讲讲细节.
顺便提一下,优化AFL的数据生成性能和同步也是一个研究方向,
关于数据生成:有一种方法就是把output目录指定在/dev/shm中,此时就是相当于把数据生成快速落地到内存,而不是磁盘,从而提升并发性能.对于跑单个程序的模糊测试来说提升不大,但是在我的工作中试过单服务器跑多个fuzz的示例,这种方式对于提升性能非常明显.不过需要考虑从Ramdisk中定时数据同步,因为关机之后所有的数据都会清空.
关于数据同步:这个数据同步不是指上面的Ramdisk中定时数据同步,是指多个AFL Fuzz实例之间的fuzz数据同步,比如说input/coverage/corpus等信息同步,参考AFL master/slave fuzz.

2. 我用了3个小时时间跑出了一个crashes，然后200G硬盘空间全部被占用导致测试中断（新建干干净净的虚拟机）。

这点并非是因为fuzz的原因,是因为ImageMagic每次处理都会在/tmp目录生成很多临时数据,但是没有主动去删除.当初我的解决方法就是简单地用脚本https://github.com/lcatro/Fuzzing-ImageMagick/blob/master/imagemagick_temp_file_delete.py来定时删除,这样就可以规避磁盘爆炸的问题.