Dynamic tools to detect vulnerabilities in software applications written in c?

• Avalanche is a dynamic defect detection tool that generates "inputs of death" - input data reproducing critical bugs and vulnerabilities in the analysed program.

• BoundsChecker is a memory checking and API call validation tool used for C++ software development with Microsoft Visual C++.

• Valgrind is an instrumentation framework for building dynamic analysis tools. There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail.

• !exploitable (pronounced “bang exploitable”) is a Windows debugging extension (Windbg) that provides automated crash analysis and security risk assessment. The tool first creates hashes to determine the uniqueness of a crash and then assigns an exploitability rating to the crash: Exploitable, Probably Exploitable, Probably Not Exploitable, or Unknown.

I usually use fuzzing in order to identify vulnerabilities in software with or without the source code. The fuzzing technique consists on manipulating the inputs to an application in a semi-automated way to produce errors that you have to study later using a debugger or inspecting the source code.

For example, you can program a fuzzer for the PDF format and use it to generate malformed PDF files and open them with your software that is supposed to fail gracely when reading malformed PDFs.

With a fuzzer you can test thousands of different combinations of inputs covering lots of cases but it is method that does not guarantee that there are no bugs.

You can use the Peach Fuzzing Platform that is a good framework to implement fuzzers and includes the tools to open the debugger automaticaly and logging the inputs when a bug is found.

Detecting vulnerabilities in C code is hard science and still an open problem. The best known tool for that is still the human brain. This is called code review. This kind of things work is you take care to put the burden of proof on the developer.

Indeed, the common situation is that the developer produced the code, then the reviewer tries to make sense out of it. But the developer will not fix anything until the reviewer demonstrates a vulnerability. That's what occurs in a lot of software projects in which the "reviewers" are "the Internet at large", and the software vendor proposes a patch only when an actual exploit has been found and published. This is quite unsatisfying.

Instead, have the developer writes clear code with lots of comments, so that a reviewer with access to the source code can understand what the code does, and see why the buffers are obviously not overflown. Under these conditions can code review be efficient, mainly because it forces the developer to himself have a clear view of his own task.

Dynamic tools like Valgrind are great as debugging tools, but not so great at detecting potential vulnerabilities. They will tell you whether a buffer overflow has occurred during tests, not whether an overflow could have occurred with different input data.

C is a difficult language because you have to think of everything. One common source of buffer overflows in C is handling of character strings, because C does not have character strings worth that name, only array of characters with the convention of a terminating zero. Other programming languages will offer real strings which can be concatenated and split and shared as if they were mere integers; such strings avoid a lot of buffer overflows by simply being much simpler to use. Of couse, simple-to-use strings require some sort of automatic memory management, be it a garbage collector or reference counting (to some extent, C++ can do reference counting for strings, but you still need to convert back to arrays of chars when interacting with the operating system).

None of the above directly applies to your problem of detecting vulnerabilities in existing applications. It just shows that your task is hard. It can be proven that it is impossible in all generality (you may never automatically detect all vulnerabilities).

You can always try to decompile programs, but the outcome can vary strongly, so if the tool is supposed work at least semi-automatic, I guess what you are asking for is fuzzing, at least for already compiled code this is a way.

I'm not sure why you'd try to do dynamic analysis, but if you have the code, I'd recommend you take a look at static analysis.

EDIT: Comes to mind, also hard science, check out articles to Computer-Supported Modeling and Reasoning. Proof your code is correct instead of finding errors could be something worth looking into for you.