Hi, for my final thesis I choose to elaborate about fuzzing. When I will defending my thesis I should have some results, some bugs. I would like to test some unix program but I need to choose carefully. I need the probability of finding a bug to be the greatest.
Any ideas?
Thank you!
If I understand your request correctly, you want to create an environment that makes it easy to defend your position by generating results you expect to be correct? I'm not sure that is the proper approach.
What exactly are you 'fuzzing'? What do you expect your fuzz to produce when it is successful? When it fails? What types of bugs are you after that can not already be caught by static analysis or commonly available tools?
What is the central argument of your thesis?
Thank you for your response.
you want to create an environment that makes it easy to defend your position by generating results you expect to be correct?
I want to avoid to test some program which is widely used or critical for the system because there is almost certain it is regularly fuzzed, so finding a bug would be uncertain and I would spend lot of time creating a fuzzer with no result. I would probably fail my defending.
What exactly are you 'fuzzing'?
Some program with command-line input.
What do you expect your fuzz to produce when it is successful? When it fails?
To dump a core for the analysis.
What types of bugs are you after that can not already be caught by static analysis or commonly available tools?
Memory leaks, buffer overflows, implementation errors, etc.
What is the central argument of your thesis?
It's "just" a bachelor thesis and basically it will be about what fuzzing is, it's importance, how it's done and some practical part with results.
Alright, that frames the problem better.
My follow-up questions are:
For memory leaks and buffer overflows, there are many tools already available for both source and binary programs that will help identify locations to focus on. There are also fuzzing tools available that you can build upon.
I'd suggest the following (in increasing diffilculty):
Thank you for your response.
It will be 'black box' fuzzing environment. Problem is that I am not sure what exact program to fuzz.
Well, in the black box sense, you aren't given the luxury of choosing. Generally, you are given the box and have to figure out what to do with it. If you are able to choose your own application/program then I would say that you really fall into the second category.
You might want to look at open-source projects focused around a particular functionality. For example, you might choose to look at spreadsheet applications. Now you do a search of open source spreadsheet implementations select a few (from very rudimentary to something like libre office).
Chances are, in the early stage projects you will find at least one bug using know fuzzing tools (or even writing a simple one yourself). As you increase the robustness of the software the less likely you are to find a bug without exponential effort.
This is funny because there was just a guy presenting a fuzzing tool for testing Clang (the C / C++ / Obj-C compiler), check it out here. This is really cool stuff, especially the afl-fuzz tool.
I want to avoid to test some program which is widely used or critical for the system because there is almost certain it is regularly fuzzed, so finding a bug would be uncertain and I would spend lot of time creating a fuzzer with no result.
I don't think that fuzzing it done as routinely as you think or would hope it is. And as far as "widely used or critical" software not having bugs to be discovered this way is also a somewhat optimistic / naive view of things. Complex systems are complex, there are few pieces of complex software that are not full of bugs.
Surely, if you consider security-critical software, then there is probably a high chance that they are being fuzzed regularly. But lots of other tools are not security-critical and therefore, just deal with bug reports from users (and use only the more basic self-tests like unit-tests).
Problem is that I am not sure what exact program to fuzz.
Anything that is based on doing complex parsing tasks is certainly going to trigger a huge load of fuzz failure reports. I wouldn't be surprized if even some of the more well-establish tools like "grep", "sed", "awk", and so on have a lot of bugs that fuzzing would discover. One suggestion is graphviz (the "dot" utility) which I know is super-buggy and very incompetently written. Another rich set of programs would be all the typesetting programs, like latex programs (tex, pdftex, latex, pdflatex, ...) or pdf conversion tools (e.g., PoDoFo), i.e., you can use all the pdfs in the world as sources for generating the fuzzed inputs. You might also target document generation systems like doxygen or javadoc, which, again, gives you a wealth of source material to fuzz.
One thing's for sure, unknown bugs are never going to be in short supply!!
Thank you for your recommendation. My apologies for not responding for a while.
I chosed to fuzz Zip file format via intelligent brute force fuzzing method and found bugs in two programs.
Some of the new mock tools are useful for unit testing software. I would like to see more of your "fuzzy" methodology that uncovered these bugs. Code is good...
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.