Replies: 1 comment · 3 replies
-
|
Many things that are not good :) fastresume.bin only helps you if the target binary did not change - so was not recompiled sind the last run. otherwise it will detect there is a change and perform calibration - and ignore the data in fastresume.bin (it has to!). also if you can use fastresume.bin, you cannot restart with additional new inputs. IF the target binary did not change, and you want to restart AND add new seeds, then you just start normally with But TLDR: fastresume.bin wont help you because of the target was recompiled, right? Finally some words about Fuzzing in a CI. bad idea. usually a very bad idea. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @vanhauser-thc for clarifying about About CI-Fuzzing, you are spot on about the PR blocking issue. The way things are set up now is to not run on every PR (because as you said- 1. it's time consuming, and 2. a crash may not be due to the PR commits). Instead, we do one daily scheduled run for 4 hours on Another factor that led to CI-Fuzzing: Being a startup, engineering velocity is currently too fast, and therefore renders harness outdated pretty quickly. If anything is more frustrating that not finding bugs- it is harness that fails to build because something changes in the dependencies/target class every now and then. Hence, we are also planning to build the fuzz targets using So tl;dr: Do you think it can slightly improve efficiency if we upload the |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like a good apporach to me, but why only fuzz for 4 hours instead of 23-24? |
Beta Was this translation helpful? Give feedback.
-
|
4 hours because Github Actions limits self-hosted runner jobs to 6 hours. We are currently building harnesses w/o ccache, so factoring all the pre-fuzzer steps (deps installation + harness build) and post-fuzzing steps (crash detection + corpus and crash uploads), we are quite limited on the runtime. Guess once we turn on caching, we can bump that to 5 hours easy. Thanks for reminding about corpus trimming, it def makes no sense to seed AFL++ with redundant test cases. Maybe I'll run Regarding corpus maintenance, this is really another important aspect. Right now, we don't foresee a situation where a harness rewrite will completely make the existing seed useless. There are other interfaces we fuzz (like file format parsers) where corpus maintenance is really important and needs to be structured/maintained around the harness logic. I am planning a fun PoC with LLMs to seed fuzzers on the fly, that will eliminate the onus of maintaining extensive corpuses at repo level. We could extend the wrapper script(s) that control the CI-fuzzing campaigns, to also generate LLM prompts for creating input seeds before starting the fuzzer. :) |
Beta Was this translation helpful? Give feedback.
-
I am implementing CI-fuzzing to stress an SQL parser, for which the input corpus is a set of various queries supported by the database. Since the database is quickly growing, there will be new syntaxes and functions supported that will need to get added to the corpus from time to time.
In our current setup, we maintain this corpus under the same project repo where we keep the harness. Today, when a CI fuzzing campaign starts, it re-seeds the fuzzer with the entire input corpus. Before the job ends, crash data is uploaded to an internal S3 for analysis.
This ofc is not efficient in the long run, so I am thinking of saving the entire output (
queue,fastresume.bin..) , and merging the previous queue with the incrementally updated input seed before the next run.The problem is, I can't seem to understand how the fuzzing will be impacted, if I execute
afl-fuzz -i merged_seed_with_previous_queue -o folder_containing_fastresume.bin /path/to/target. OTOH, AFL++ allows fuzz resumption with thei -flag, but then I miss out on seeding it with the new inputs.Would appreciate some leads here. TIA!
Beta Was this translation helpful? Give feedback.
All reactions