大佬好，按照你的步骤去做，结果出了些问题

[loveraven42]

我在虚拟机ubantu 16.04LTS运行这步的时候，它提示物 magick 是个shell文件

afl-fuzz -i ../../fuzzdata/samples/png -o fuzzing_output -t 300000 -m 200 ./magick convert @@ /dev/null

然后我去网上查了下 shell文件转换成 binary文件时也没找到什么好的方案
希望大佬告诉我下应该怎么解决
我的afl是2.51b版本
ImageMagick是今天的版本
具体图片如下:

[lcatro]

@akamei 这个意思是./magick 是一个脚本,不能够作为afl-fuzz 的测试输入程序,一般来说,编译成功之后,在当前目录的.libs 下有一个二进制文件的,用afl-fuzz 跑的是那个二进制文件,不是这个sh 脚本文件,你可以使用file 命令来重新确认文件格式..

[loveraven42]

谢谢大佬，我找到那个文件了:)

[wnagzihxa1n]

感谢！

[insidemountain]

你好，ImageMagick的版本现在已经更新了，还能用fuzz跑出那些cve吗？当时你跑的最新版本的时候，可以跑出旧的crash吗？

[lcatro]

@insidemountain 无论版本怎么更新,潜在的问题肯定是会有的,要看挖掘的方法和思路.Fuzzing 只是一个思路,我自己得出的一点经验,挖二进制漏洞Fuzzing 很重要,配合看源码也很重要,因为读源码的过程中可以知道更多的细节,比如可以针对一些特性或者新版本支持的功能和关键字来Fuzzing ,这种问题可能用旧的样本是跑不出来的.在当时最新版的时候,用别人的样本还是可以跑到一些问题来,建议你可以到各个Bug Issus 平台上收集样本,当时我的样本从Firefox ,ImageMagic 之前提交过的有问题的样本,libPNG ,OpenJPEG 等库的测试用例上拿样本,而且这些样本无论是跑ImageMagic 还是GraphicsMagic ,只要是可以解析这种图像格式的库和代码,都可以用收集到的样本来跑跑看,试试有没有问题.希望对你有帮助~

[insidemountain]

@lcatro 十分感谢你的分享，对我帮助很大。 我还有点疑惑，就是我看到你写的文档是从最新的源码编译然后进行的fuzz，仍旧跑出来了旧版本的7个cve（还是这7个cve是你新跑出来的，如果是的话，我可能不理解错了，不好意思，主要是想知道，我下载最新的版本能不能分析旧版本的cve，最近想复现一下cve），这7个漏洞不应该已经被打了补丁了吗，为什么还会出现crash呢？

[lcatro]

@insidemountain 建议切换到旧版本来复现漏洞,因为开源项目经过多次修改代码之后可能和原来的代码完全不同,这7 个crash 你可以看一看崩溃的原因和触发漏洞的代码位置,因为旧的crash 样本也可以能会触发崩溃,如果是新的代码位置产生崩溃的话,这个就算是找到了新洞,恭喜CVE ..

[lcatro]

@insidemountain 至于最新版本的代码可以触发旧版本修复的Crash 原因,有些开发者会认为一些崩溃(比如说空指针,栈溢出[指的是不断地递归调用那种栈溢出,不是缓冲区溢出])对项目影响不大,会有选择性地修复,或者在开发过程中不知道什么时候产生了代码版本回撤,导致原本修改的代码被撤消了,你也可以从Commit 的历史里面找找..

[insidemountain]

非常感谢耐心地为我解答疑惑，由于我比较少上github，所以回复较慢，请多包涵。

[lcatro]

@insidemountain 小事哈,如有问题留言就好了~

[loveraven42]

lc师傅， 用深度学习挖二进制漏洞是否可行？ 也许是我眼界低， 个人认为深度学习在fuzz和符号执行的情况下似乎帮不了什么忙， 但是又有GGC的比赛表明可以用深度学习的方法进行漏洞挖掘与修补， 想听下你的经验。

[lcatro]

@akamei 目前我了解到的深度学习应用到Fuzzing 的一个例子是微软研究院的论文Learn&Fuzz:
Machine Learning for Input Fuzzing (https://arxiv.org/pdf/1701.07232.pdf ) .这个论文主要是说了用深度学习来学习样本并且生成新的样本的操作.其他关于机器学习在挖洞方面的应用我也还在研究,不过还没什么进展,毕竟太复杂了.GGC 的比赛还没了解过就不多说了哈,我觉得如果还要让深度学习达到漏洞修补的话,估计还是需要用到一些白盒的数据流分析功能.
话说回来,CTF 本身题目,解题总是有很多不同的思路,而且CTF 题目也基本上套路都差不多,有些二进制的题目和MISC 还可以用符号执行和Z3 来解,在真实的场景下能这么用是比较少的,我觉得比较可行的是在区块链的智能合约自动化审计上来用Z3 求解判断,因为智能合约的代码量少,能够保证约束可以被求解.
不过真实环境下的漏洞挖掘,还是得需要结合Fuzzing 的对象来讨论的:如果是要Fuzzing 一些图像解析库和网络协议库的话,大部分情况下纯随机的字符串就可以解决了,有些特定的位置可能需要插个标识和校验字符串;如果要Fuzzing JavaScript PHP 这些解析器的话,就需要按照一定的语句执行规则来生成代码给解析器执行,参考:https://github.com/tunz/js-vuln-db .生成代码语句还是有一定规律的,那么就可以应用到机器学习来拆分样本和PoC 来学习代码结构;最理想的Fuzzing 是要达到100 % 的代码覆盖率,这种情况是不可能的,所以在Fuzzing 的过程中最希望越高的代码覆盖率越好,所以符号执行可以帮助你挖掘什么样的数据可以触发哪些路径,在下一次生成数据的时候就可以根据前面生成的Fuzzing 数据触发的路径来调整当前生成的Fuzzing 数据..

[loveraven42]

lc师傅好强， 带带我fuzz和吃鸡:)， 可不可以偷偷发你微信到我邮箱里wxhusst@gmail.com @lcatro

[thinkycx]

同样遇到了这个问题，用ImageMagick/utilities/.libs/magick 文件。
或者编译时加上--disable-shared选项，但是即使在编译时加上了-g选项，这种方式还是会导致没有符号。

[lcatro]

@thinkycx 你可以试试在gcc 中重新编译一次看看..

[thinkycx]

确实，如果用gcc编译时看log是有符号信息的。

用clang+ASAN编译时就没有符号信息（具体体现在遇到了ASAN的报错，只会显示magic+0xXX出了问题，但是不会显示对应的源码是第几行）因此就无法定位到是源码中的第几行出了问题了。

排查了一下clang编译后的binary，使用file命令查看magick二进制文件是没有strip的，gdb加载该binary后，运行poc后，如果使用CTRL+C暂时中断程序，是可以看到对应的符号的，只是ASAN的log中没有符号。

请问这可能是什么原因导致的呢？ @lcatro

环境：

• ubuntu18.04 / ubuntu16.04均测试过
• clang 3.8.0和3.9.0均测试过

举例：
gcc:

==2775==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/sanitizer_common/sanitizer_common.cc:118 "((0 && "unable to mmap")) != (0)" (0x0, 0x0)
    #0 0x7fa33ed0ec02  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe9c02)
    #1 0x7fa33ed2d595 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x108595)
    #2 0x7fa33ed18492  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xf3492)
    #3 0x7fa33ed248a5  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xff8a5)
    #4 0x7fa33ec518f1  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x2c8f1)
    #5 0x7fa33ec4c1ad  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x271ad)
    #6 0x7fa33ed04763 in posix_memalign (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdf763)
    #7 0x7fa33e3576d4 in AcquireAlignedMemory MagickCore/memory.c:265
    #8 0x7fa33e357a6e in AcquireVirtualMemory MagickCore/memory.c:621
    #9 0x7fa33e4f20fb in ReadBMPImage coders/bmp.c:983
    #10 0x7fa33e1dc431 in ReadImage MagickCore/constitute.c:547
    #11 0x7fa33e1df3a0 in ReadImages MagickCore/constitute.c:919
    #12 0x7fa33daa3d9a in ConvertImageCommand MagickWand/convert.c:644
    #13 0x7fa33db9e741 in MagickCommandGenesis MagickWand/mogrify.c:184
    #14 0x559edc67cf00 in MagickMain utilities/magick.c:149
    #15 0x559edc67d186 in main utilities/magick.c:180
    #16 0x7fa33d3bdb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #17 0x559edc67c979 in _start (/home/thinkycx/Fuzz/fuzz-imageMagick/ImageMagick/bin-gcc/bin/magick+0x1979)

clang log:

Direct leak of 112 byte(s) in 1 object(s) allocated from:
    #0 0x4b91d8  (/root/Fuzz/fuzz-imageMagick/ImageMagick/bin-afl-clang-docker/bin/magick+0x4b91d8)
    #1 0x7ffff500703c  (/usr/lib/x86_64-linux-gnu/libomp.so.5+0x1803c)
    #2 0x7ffff500713a  (/usr/lib/x86_64-linux-gnu/libomp.so.5+0x1813a)
    #3 0x7ffff5027454  (/usr/lib/x86_64-linux-gnu/libomp.so.5+0x38454)
    #4 0x7ffff501cf4e  (/usr/lib/x86_64-linux-gnu/libomp.so.5+0x2df4e)
    #5 0x7ffff6f761fc  (/root/Fuzz/fuzz-imageMagick/ImageMagick/bin-afl-clang-docker/lib/libMagickCore-7.Q16HDRI.so.6+0x5f91fc)
    #6 0x7ffff74b521e  (/root/Fuzz/fuzz-imageMagick/ImageMagick/bin-afl-clang-docker/lib/libMagickCore-7.Q16HDRI.so.6+0xb3821e)
    #7 0x7ffff6cffabc  (/root/Fuzz/fuzz-imageMagick/ImageMagick/bin-afl-clang-docker/lib/libMagickCore-7.Q16HDRI.so.6+0x382abc)
    #8 0x7ffff6d03e2c  (/root/Fuzz/fuzz-imageMagick/ImageMagick/bin-afl-clang-docker/lib/libMagickCore-7.Q16HDRI.so.6+0x386e2c)
    #9 0x7ffff63c68cf  (/root/Fuzz/fuzz-imageMagick/ImageMagick/bin-afl-clang-docker/lib/libMagickWand-7.Q16HDRI.so.6+0x18d8cf)
    #10 0x7ffff64f6e57  (/root/Fuzz/fuzz-imageMagick/ImageMagick/bin-afl-clang-docker/lib/libMagickWand-7.Q16HDRI.so.6+0x2bde57)
    #11 0x4eadb7  (/root/Fuzz/fuzz-imageMagick/ImageMagick/bin-afl-clang-docker/bin/magick+0x4eadb7)
    #12 0x7ffff4a2f82f  (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: 528 byte(s) leaked in 2 allocation(s).

[thinkycx]

解决了。@lcatro

clang开启ASan编译选项时，calltrace中的符号信息是依赖llvm的llvm-symbolizer来做的。因此确保llvm-symbolizer在环境变量中即可。

详细可以参考这里：google/sanitizers#1043

[lcatro]

@thinkycx 感谢老哥分享,Get 到新方式,刚才在开会弄了好久,没来得及回复不好意思哈~

[lcatro]

@thinkycx 之前我也遇到这个没有符号的问题,我都是先clang++ -o 2 跑完然后出问题了没找到符号再到gcc 从新编译一次然后再跑一下的..

[thinkycx]

客气了，向前辈学习。