Tools & Tips for auditing code

Tool(s) I wrote for testing programs

• Gibberish
  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.
  gibberish-0.2.tar.gz
  

Other tools for finding flaws:

• A boundscheckerpatch for GCC: http://web.inter.nl.net/hcc/Haj.Ten.Brugge/
• Valgrind, an open-source memory debugger for x86-GNU/Linux: http://developer.kde.org/~sewardj/
• C++ lint: http://sourceforge.net/projects/clint/
• flawfinder, a program that examines source code and reports possible security weaknesses (``flaws'') sorted by risk level: http://www.dwheeler.com/flawfinder/
• RATS, same as flawfinder (+/-): http://www.securesoftware.com/download_form_rats.htm

• PScan: A limited problem scanner for C source files: http://www.striker.ottawa.on.ca/~aland/pscan/
• Splint is a tool for statically checking C programs for security vulnerabilities and coding mistakes: http://splint.org/
• Cqual is a type-based analysis tool that provides a lightweight, practical mechanism for specifying and checking properties of C programs: http://www.cs.berkeley.edu/~jfoster/cqual/
• MOPS is a tool for finding security bugs in C programs and for verifying conformance to rules of defensive programming: http://www.cs.berkeley.edu/~daw/mops/
• BOON is a tool for automatically finding buffer overrun vulnerabilities in C source code: http://www.cs.berkeley.edu/~daw/boon/
• Blast verifies and certifies temporal safety properties of C progams by model-checking a lazily-refined conservative abstraction of the program: http://www-cad.eecs.berkeley.edu/~rupak/blast/
• LCLint: http://lclint.cs.virginia.edu/
• ITs4: http://www.cigital.com/its4/
• Smatch (specifically aimed at the Linux kernel): http://smatch.sourceforge.net/
• The Stanford Checker (idem): http://metacomp.stanford.edu/

Documentation:

• making code 64bit clean: http://www.treblig.org/articles/64bits.html
• Secure Programming for Linux and Unix HOWTO: http://www.dwheeler.com/secure-programs/
• Secure, Efficient and Easy C programming: http://irccrew.org/~cras/security/c-guide.html
• Guidelines for C source code auditing: http://mixter.void.ru/vulns.html
• Robust Programming: http://nob.cs.ucdavis.edu/~bishop/classes/ecs153-1998-winter/robust.html
• Writing Safe Setuid Programs: http://nob.cs.ucdavis.edu/~bishop/secprog/index.html
• Secure UNIX Programming FAQ: http://www.whitefang.com/sup/secure-faq.html
• Secure Internet Programming: http://www.cs.princeton.edu/sip/
• How To Find Security Holes: http://www.pobox.com/~kragen/security-holes.html
• Best Practices for Secure Development: http://members.rogers.com/razvan.peteanu/best_prac_for_sec_dev4.pdf
• Steve Bellovin's "Shifting the Odds": http://www.research.att.com/~smb/talks/odds.pdf
• "Secure Programming Checklist" from Practical UNIX and Internet Security: ftp://ftp.auscert.org.au/pub/auscert/papers/secure_programming_checklist
• Writing priveleged programs: http://www.crimelabs.net/docs/sec-programming.ps
• Avoiding Security Holes when developing an Application: http://mercury.chem.pitt.edu/~tiho/LinuxFocus/English/January2001/article182.shtml
• NSCA Secure Programming Guidelines: http://archive.ncsa.uiuc.edu/General/Grid/ACES/security/programming/

How "they" exploit vulnerabilities

• Smashing the Stack for Fun and Profit: http://www.shmoo.com/phrack/Phrack49/p49-14
• Exploiting Format String Vulnerabilities: http://www.team-teso.net/releases/formatstring.pdf

Tips

• 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

Books

• Building Secure Software by John Viega and Gary McGraw
• Practical UNIX and Internet Security 2nd Ed. from O'Reilly
• Writing Solid Code by Steve Maguire
• The Practice of Programming by Kernighan and Pike
• Programming Windows Securityby Keith Brown
• Code Complete by Steve McConnel
• Writing Secure Code by Howard and LeBlanc

Mailing Lists

Misc.

• Cacheprof is a tool designed to help programmers quantify and understand the cache behaviour of programs and algorithms. With this knowledge, you might be able to modify your code to be more cache-friendly and thereby faster. http://www.cacheprof.org/
• David A. Wheeler's Java Security Tutorial: http://www.dwheeler.com/javasec/
• Twelve rules for developing more secure Java code: http://www.javaworld.com/javaworld/jw-12-1998/jw-12-securityrules.html
• Writing Secure Java Programs: http://www.networkcomputing.com/1108/1108ws3side1.html
• Frequently Asked Questions - Java Security (SUN Microsystems): http://java.sun.com/sfaq/
• Secure Java programming for Wireless devices: http://sg.sun.com/events/presentation/files/j2me/SrikanthRaju_WirelessSecurity.pdf
• Security Code Guidelines: http://java.sun.com/security/seccodeguide.html
• Safe CGI Programming: http://www.go2net.com/people/paulp/cgi-security/safe-cgi.txt
• Perl CGI Problems: http://www.insecure.org/news/P55-07.txt