Wednesday, 27 November 2019

Twice and thrice over, as they say, good is it to repeat and review what is good.

Three years ago I wrote about using the AFL fuzzer to find bugs in several NetSurf libraries. I have repeated this exercise a couple of times since then and thought I would summarise what I found with my latest run.

I started by downloading the latest version of AFL (2.52b) and compiling it. This went as smoothly as one could hope for and I experienced no issues although having done this several times before probably helps.


I started with libnsbmp which is used to render windows bmp and ico files which remains a very popular format for website Favicons. The library was built with AFL instrumentation enabled, some output directories were created for results and a main and four subordinate fuzzer instances started.

vince@workshop:libnsbmp$ LD=afl-gcc CC=afl-gcc AFL_HARDEN=1 make VARIANT=debug test
afl-cc 2.52b by <>
afl-cc 2.52b by <>
afl-cc 2.52b by <>
 COMPILE: src/libnsbmp.c
afl-cc 2.52b by <>
afl-as 2.52b by <>
[+] Instrumented 633 locations (64-bit, hardened mode, ratio 100%).
      AR: build-x86_64-linux-gnu-x86_64-linux-gnu-debug-lib-static/libnsbmp.a
 COMPILE: test/decode_bmp.c
afl-cc 2.52b by <>
afl-as 2.52b by <>
[+] Instrumented 57 locations (64-bit, hardened mode, ratio 100%).
    LINK: build-x86_64-linux-gnu-x86_64-linux-gnu-debug-lib-static/test_decode_bmp
afl-cc 2.52b by <>
 COMPILE: test/decode_ico.c
afl-cc 2.52b by <>
afl-as 2.52b by <>
[+] Instrumented 71 locations (64-bit, hardened mode, ratio 100%).
    LINK: build-x86_64-linux-gnu-x86_64-linux-gnu-debug-lib-static/test_decode_ico
afl-cc 2.52b by <>
Test bitmap decode
Tests:1053 Pass:1053 Error:0
Test icon decode
Tests:609 Pass:609 Error:0
    TEST: Testing complete
vince@workshop:libnsbmp$ mkdir findings_dir graph_output_dir
vince@workshop:libnsbmp$ afl-fuzz -i test/ns-afl-bmp/ -o findings_dir/ -S f02 ./build-x86_64-linux-gnu-x86_64-linux-gnu-debug-lib-static/test_decode_bmp @@ /dev/null > findings_dir/f02.log >&1 &
vince@workshop:libnsbmp$ afl-fuzz -i test/ns-afl-bmp/ -o findings_dir/ -S f03 ./build-x86_64-linux-gnu-x86_64-linux-gnu-debug-lib-static/test_decode_bmp @@ /dev/null > findings_dir/f03.log >&1 &
vince@workshop:libnsbmp$ afl-fuzz -i test/ns-afl-bmp/ -o findings_dir/ -S f04 ./build-x86_64-linux-gnu-x86_64-linux-gnu-debug-lib-static/test_decode_bmp @@ /dev/null > findings_dir/f04.log >&1 &
vince@workshop:libnsbmp$ afl-fuzz -i test/ns-afl-bmp/ -o findings_dir/ -S f05 ./build-x86_64-linux-gnu-x86_64-linux-gnu-debug-lib-static/test_decode_bmp @@ /dev/null > findings_dir/f05.log >&1 &
vince@workshop:libnsbmp$ afl-fuzz -i test/ns-afl-bmp/ -o findings_dir/ -M f01 ./build-x86_64-linux-gnu-x86_64-linux-gnu-debug-lib-static/test_decode_bmp @@ /dev/null

The number of subordinate fuzzer instances was selected to allow the system in question (AMD 2600X) to keep all the cores in use with a clock of 4GHz which gave the highest number of
AFL master instance after six days
executions per second. This might be improved with better cooling but I have not investigated this.

After five days and six hours the "cycle count" field on the master instance had changed to green which the AFL documentation suggests means the fuzzer is unlikely to discover anything new so the run was stopped.

Just before stopping the afl-whatsup tool was used to examine the state of all the running instances.

vince@workshop:libnsbmp$ afl-whatsup -s ./findings_dir/
status check tool for afl-fuzz by <>

Summary stats

       Fuzzers alive : 5
      Total run time : 26 days, 5 hours
         Total execs : 2873 million
    Cumulative speed : 6335 execs/sec
       Pending paths : 0 faves, 0 total
  Pending per fuzzer : 0 faves, 0 total (on average)
       Crashes found : 0 locally unique

Just for completeness there is also the graph of how the fuzzer performed over the run.

AFL fuzzer performance over libnsbmp run

There were no crashes at all (and none have been detected through fuzzing since the original run) and the 78 reported hangs were checked and all actually decode in a reasonable time. It seems the fuzzer "hang" detection default is simply a little aggressive for larger images.


I went through a similar setup with libnsgif which is used to render the GIF image format. The run was performed on a similar system running for five days and eighteen hours. The outcome was similar to libnsbmp with no hangs or crashes.

vince@workshop:libnsgif$ afl-whatsup -s ./findings_dir/
status check tool for afl-fuzz by <>

Summary stats

       Fuzzers alive : 5
      Total run time : 28 days, 20 hours
         Total execs : 7710 million
    Cumulative speed : 15474 execs/sec
       Pending paths : 0 faves, 0 total
  Pending per fuzzer : 0 faves, 0 total (on average)
       Crashes found : 0 locally unique


AFL fuzzer results for libsvgtiny
I then ran the fuzzer on the SVG render library using a dictionary to help the fuzzer cope with a sparse textural input format. The run was allowed to continue for almost fourteen days with no crashes or hangs detected.

In an ideal situation this run would have been allowed to continue but the system running it required a restart for maintenance.


The aphorism "absence of proof is not proof of absence" seems to apply to these results. While the new fuzzing runs revealed no additional failures it does not mean there are no defects in the code to find. All I can really say is that the AFL tool was unable to find any failures within the time available.

Additionally the AFL test corpus produced did not significantly change the code coverage metrics so the existing set was retained.

Will I spend the time again in future to re-run these tests? perhaps, but I think more would be gained from enabling the fuzzing of the other NetSurf libraries and picking the low hanging fruit from there than expending thousands of hours preforming these runs again.


  1. شركة تنظيف مكيفات بالرياض
    تمتلك افضل الطرق والمعدات في تنظيف الواحدات الداخلية والخارجية للمكيفات توفر تنظيف المكيفات الاسبلت الكاست شركة غسيل مكيفات توفر خدمة تعبئة الفريون بسعر مميز نظافة المكيفات تساعد علي رفع كفاءة التشغيل مرة اخري.

    المجالس تعتبر من أهم الأغراض المنزلية والمكتبية المستخدمة في مكان وهي تأتي بعدد كبير من الأشكال والأحجام والألوان المتنوعة التي تجعل تنظيفها صعب ومرهق في الكثير من الأحيان ؛ ولكننا عبر شركة تنظيف مجالس بالرياض نُقدم إلى كل ربة منزل الحل الأمثل من خلال أفضل خدمات تنظيف المجالس العميقة والشاملة القادرة على إزالة أصعب البقع والعلامات بسهولة فائقة ، حيث أن الشركة قد قامت باستيراد أفضل الأجهزة والمعدات وخوصًا آلة التنظيف بالبخار التي تعطي أفضل مستوى نظافة على الإطلاق ، ونحن نقوم اولًا بتحديد نوع المجالس ومن ثم اختيار طريقة التنظيف المناسبة حتى لا يتعرض إلى أي تلفيات أو أضرار ، وكل ذلك مُقدم لكم بأقل الأسعار على الإطلاق مع العديد من الخصومات والتخفيضات الهائلة.

    تضطر ربات البيوت إلى قضاء أوقات طويلة في تنظيف الشقق ومع ذلك لا تصل إلى درجة النظافة المطلوبة ؛ ولذلك فقد قررت شركة تنظيف شقق بالرياض أن توفر على كل امرأة كل هذا العناء وأن تُقدم لها خدمة تنظيف جميع أنواع الشقق سواء العادية أو الدوبليكس أو المفروشة أو الحديثة والتي لا زالت تحت الإنشاء أو غيرها بأقل وأرخص الأسعار على الإطلاق.

    نقدم خدماتنا شركة تنظيف موكيت بالرياض مثل غسيل الموكيت والسجاد وغيرها فالهدف الاول هو راحة العملاء و اكتساب ثقتهم مهما تكلف الامر مع ضمان جودة الخدمات المقدمة سرعة انجازها بكل سهوله و امان و على احدث و افضل الاساليب.

    بالطبع يكون عمل تنظيف المساجد أكثر صعوبة حيث أن المساجد هي بيوت الله تعالى ومن الضروري أن تبقى مفتوحة دائماً لأداء الصلوات الخمس وعلي الشركة إتمام مهمة تنظيف الموكيت في أسرع وقت ويتم تجفيفه أيضا حتي يصبح جاهزاً للفرش والصلاة عليه في أوقات الصلوات الخمس دون تأخير .
    شركة تنظيف مساجد بالرياض