The Fuzzing Project is run by Hanno Böck
A very basic and simple to use fuzzing tool is zzuf by Sam Hocevar. It operates without any knowledge of the file format just by creating random modifications of a given input.
One of the most advanced fuzzing tools these days is american fuzzy lop (afl) by Michal Zalewski. It fuzzes applications by adding compile-time instrumentation that allow afl to analyze code paths. Once new code paths are found these inputs are used as starting points for further fuzzing. This can lead to very impressive results.
Fuzzing with any tool can gain additional strength by using Address Sanitizer (ASan). This is a compile-time switch in current versions of gcc and llvm that adds additional bounds checks for memory access errors. It can enabled by simply adding -fsanitize=address to the CFLAGS. ASan doesn't always play well with existing fuzzing tools (using export ASAN_OPTIONS='abort_on_error=1' and disabling memory limits sometimes helps).
This list is far from complete, there are countless fuzzing tools out there.
Unfortunately it is often not trivial to decide whether a Segfault points to a security issue or not. That's not made easier by the fact that often people can't even agree what a security issue is. For some applications a crash may already be considered a security issue (just think of an office application crashing while you were editing some important document).
Running the crashing software through valgrind or enabling ASan can usually give a first pointer what is going on. There are some rules of thumb. Read errors are usually less severe than write errors (however there are exceptions - Heartbleed was "just" an out of bounds read error).
If the security state of a bug is unknown it is wise to neither overblow the issue nor downplay it. Experience has shown that even bugs that look minor can be exploited.
If you find something report it to the developers. Please do this in a reasonable way. Be polite, make sure you give them the impression you want to improve their product, not tell them they're stupid. Consider responsible disclosure if the bugs you find look like security issues.
Send me links to public bug reports / mailing list archives if you find something. Send me a quick report of what you did if you find nothing.
Arguments like this come up quite often. Modern opeating systems already ship a bunch of techniques like Stack Canaries or Address Space Layout Randomization (ASLR) to make exploiting security bugs harder. Browsers and other software highly exposed to security issues use differet kinds of sandboxing. The problem with mitigation is that these strategies are either incomplete or impractical. That doesn't mean mitigation is bad. It should be seen as a complementary strategy to fixing bugs.
If you are curious what mitigation techniques the executables on a Linux system use have a look at checksec. If you want to have a look at a thorough strategy to fix memory access issues for good you may want to have a look at Softbound+CETS.
This comes up quite often, the problem with it is that very few people actually do that. There are memory safe languages and if you start a new software project it is a good idea to avoid C right from the start.
It is however a fact that most major software components we use today (operating systems, browsers, ...) in our systems is written in C. That won't change any time soon. Rewriting things from scratch is hard, compared to that finding bugs with fuzzing is the low hanging fruit.
There are very few projects that try to rewrite key software with memory safe languages. Two very promising ones are miTLS (a verified TLS implementation in F#) and Servo (a browser engine written in Rust).
The Fuzzing Project currently focuses on file format parsing. However every kind of input parser can be fuzzed.
Network fuzzing is often done with Scapy. If you're interested in fuzzing USB drivers you may want to have a look at vUSBf.
The Fuzzing Project is run by Hanno Böck