About objdump's crash reproduction problem

[Siyuan-Li201]

I am very interested in this artifact and I think it is very helpful. However, I encountered some problems during my use. I used your docker directly and successfully reproduced the vulnerabilities such as CVE-2016-9827 of poppler, and the time was basically consistent with the Ealuation of the paper. However, when I reproduced the three vulnerabilities CVE-2017-8392, 8396, and 8397 of objdump, I tried many times and executed for more than 24 hours, but no crash was triggered. I encountered the same problem when fuzzing CVE-2017-9047 of xmllink. I checked the distance.cfg.txt file and there is content in it. Do you know what went wrong?

The content in distance.cfg.txt are as follows:

# cat distance.cfg.txt 
objdump.c:3623,292
objdump.c:3589,280
objdump.c:3630,292
objdump.c:3632,298
objdump.c:3649,297
objdump.c:3659,292
objdump.c:3678,285
objdump.c:3716,308
objdump.c:3682,300
objdump.c:3692,297
objdump.c:3699,292
objdump.c:3103,291
objdump.c:2321,314
objdump.c:2412,310
objdump.c:2423,309
objdump.c:2435,291
objdump.c:3583,285
objdump.c:3607,286
objdump.c:3609,280
objdump.c:3471,280
objdump.c:3478,278
objdump.c:3486,281
objdump.c:3490,281
objdump.c:3501,281
objdump.c:3504,279
objdump.c:3507,307
objdump.c:3508,282
objdump.c:3511,289
objdump.c:3522,277
objdump.c:3524,275
objdump.c:3526,287
objdump.c:3528,295
objdump.c:3530,290
objdump.c:3532,304
objdump.c:3536,302
objdump.c:3554,294
objdump.c:568,288
objdump.c:587,283
objdump.c:597,291
objdump.c:2630,294
objdump.c:2684,291
objdump.c:2872,276
objdump.c:3398,291
objdump.c:3404,312
objdump.c:3420,293
objdump.c:3429,265
objdump.c:1486,37.4634
objdump.c:1679,264
objdump.c:1791,49.9512
objdump.c:2080,284
objdump.c:2155,273
objdump.c:2163,271
objdump.c:2173,269
objdump.c:2191,267
objdump.c:2245,270
objdump.c:2267,274
objdump.c:2304,264
objdump.c:1474,49.9512
objdump.c:3180,265
objdump.c:3365,272
objdump.c:3225,37.4634
objdump.c:3350,299
objdump.c:3377,268
objdump.c:3390,265
objdump.c:2855,291
prdbg.c:293,318
prdbg.c:316,318
prdbg.c:317,318
prdbg.c:2747,296
prdbg.c:2756,291
prdbg.c:1947,291
prdbg.c:1922,266
prdbg.c:1942,37.4634
debug.c:2307,318
debug.c:2350,316
debug.c:2366,316
debug.c:2373,316
debug.c:2378,316
debug.c:2382,316
debug.c:2388,315
debug.c:2391,316
debug.c:2393,316
debug.c:2395,316
debug.c:2401,316
debug.c:2819,313
debug.c:2823,311
debug.c:2808,315
debug.c:2837,305
debug.c:2847,305
debug.c:2861,301
ieee.c:4595,317
ieee.c:4623,306
ieee.c:4633,303
ieee.c:4668,291
section.c:1387,291
section.c:1395,283
elf.c:8631,8
elf.c:8680,8
dwarf2.c:4140,8
dwarf2.c:4176,8
dwarf2.c:4181,4
dwarf2.c:4210,1
dwarf2.c:4212,1
coffgen.c:2224,28.4444
coffgen.c:2505,28.4444
coffgen.c:2256,7.11111
coffgen.c:2284,16
coffgen.c:2294,8
coffgen.c:2494,28.4444

[chluo1997]

Sorry. I just found the scripts of objdump have mistakes. In https://github.com/cuhk-seclab/SelectFuzz/blob/6da35e0db9de6843db32c8ee69b41147e46c1795/scripts/fuzz/objdump-CVE-2017-8392.sh#L3, there is a command executing cp -r /binutils ./CVE-2017-8392. However, there are no /binutils! probably because I deleted it for reducing the docker image size.

To address this issue, you can comment out https://github.com/cuhk-seclab/SelectFuzz/blob/6da35e0db9de6843db32c8ee69b41147e46c1795/scripts/fuzz/objdump-CVE-2017-8392.sh#L3 and uncomment https://github.com/cuhk-seclab/SelectFuzz/blob/6da35e0db9de6843db32c8ee69b41147e46c1795/scripts/fuzz/objdump-CVE-2017-8392.sh#L1. By the way, I suspect that there are either issues in you target binaries or seeds because normally, there should be many other crashes in addition to the target crashes.

[chluo1997]

Hi Siyuan,

The seed of Objdump should be an elf file, but somehow the seed test was overridden by another file in Docker. If you type file test under scripts/fuzz, you can see LRZIP compressed data - version 0.6 (unexpected). The reason is that I used the same file name "test" as the seed for testing different binaries. As a result, the seed for Objdump was overridden by other seeds. Therefore, you need to generate the desired seed to test Objdump.

To this end, you can run the command in scripts/fuzz/keepme: gcc -g -c 1.c -o test. 1.c was a simple C file

#include <stdio.h>

int main() {
   char test_string[] = "helloworld";
   return 0;
}

You will see an ELF file under scripts/fuzz folder. This is the seed required for testing Objdump.

Attached is the running results for your reference.

[Siyuan-Li201]

Thank you very much for your reply. I modified the seed file and it works. I successfully triggered several vulnerabilities in objdump. Thanks again for your timely assistance.

Best wishes!