Tools & Tips for auditing code
All of the following tools & tips etc. apply to the wonderfull C(++) language. At the bottom, there's a special section on other languages.
Tool(s) I wrote for testing programs
Imagine that you wrote a server application for a computer in a hostile (e.g. the internet) environment. In this environment, you can be sure your program will be severly tortured in every way. With the program I wrote called gibberish, you can test your program if it can stand such attacks. It can be used to test TCP and UDP servers, the test-data can consist of random ASCII and random binary data. The program was written for the UNIX platform but can easily be ported to Windows (for example by using the Cygwin compiler) or Mac.
Other tools for finding flaws:
Note: flawfinder and rats are discussed in a LinuxJournal article 'Source Code Scanners for Better Code': http://www.linuxjournal.com//article.php?sid=5673
How "they" exploit vulnerabilities
- Look for usage of malloc, strdup(!) and friends: verify that what they return is always checked for NULL! Yes, it is always possible that even strdup()ing a string fails because of memory shortage
- Verify that when strncpy is used, that the destination string is terminated with 0x00! => strncpy will not do that for you! (unless the source-string contains a 0x00 within the number of bytes that are copied)
- read/write can come back with less bytes read/written then requested which is then not always an error-situation
- read/write/recv/recvfrom/sendto can come with -1 and errno set to EINTR, in that case the command should be executed again. EINTR is returned when a signal came in just before reading/writing/etc. However: I heard a rumour that on Linux especially with file- access, the EINTR cannot occure. But if the application you're auditing is also for other UNIX platforms, be sure to check for all of this
None found yet.
Any comments/questions? Please send me an e-mail: firstname.lastname@example.org
Last changed: October 7, 2003